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11 RATED AND WILLING 

As video game violence turns more and 
more heads as a hot-button issue, it has 
become clear that the majority of the anti- 
video game lobby, and indeed a portion of 
the development community, is under- 
informed about just how the ratings 
systems work for games. In this feature, we 
dissect the ratings systems across four 
major territories— the U.S., the U.K., 
Germany, and Australia— to give a better 
impression of how the ratings board work to 
keep games in the right hands. 

By Paul Human 



26 DESIGNING PAC-MAN 

Twenty-five years have passed since the dawn of Pac-Man. Though the 
game and its lovable hero represent the first iconic presence in games, 
the Pac-Man symbol continues to emerge on new platforms, offering new 
iterations of the original gameplay. Now, 25 years since its birth, seems 
an appropriate time to catch up with Toru Iwatani, Pac-Man's creator, to get 
a long-overdue postmortem of the original game. As a bonus, Game 
Developer's editors have written a third-party postmortem of the entire 
franchise, trying to pin down Pac-Man's continuing appeal. 

By Toru Iwatani and Simon Carless 



19 ART PIPELINE PHILOSOPHIES FOR THE 
NEXT GENERATION: A TECHNICAL ART 
DIRECTOR'S PERSPECTIVE 

As the next generation of systems unroll, 
game development will change forever. 
Fears of bigger budgets, larger teams and 
dispersed control could run wild, but as with 
any industry, the key for each individual is 
to work smarter, not harder. Rod Green 
outlines some techniques for next 
generation art pipelines that could save 
time and money as your team takes that big 
step into the next generation. 

By Rod Green 
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A LITTLE YELLOW PILL-CHOMPING GUY HAS BEEN 

featured in video games for an almost unbelievable 
quarter of a century. As you might have spotted 
from the cover, this esteemed personage would 
be Pac-Man, whose immense arcade success in 
1980 helped to kick-start the modern video 
game craze. 

To pay tribute, we've managed to get a special 
postmortem for the original Pac-Man written by its 
creator, Namco's Toru Iwatani. Iwatani talks lovingly 
about his goals when designing the title, the trials 
and tribulations of development, influences, and 
the title's effect on the gaming landscape. To back 
this up, the Gome Developer editors have weighed 
in with our own postmortem of the Pac-Man 
franchise in the 25 years since it started. What 
went wonderfully right? What went horribly 
wrong? We take an objective look (pg._26j. 

RATE MY GAME? 

This month's feature from Paul Hyman (pg.JJJ 
looks in detail at video game ratings, following a 
not-insignificant amount of controversy in the 
mainstream press over how games are rated in 
North America. Ratherthan snapping to any 
decisions, we thought it would be a good idea to 
investigate exactly how other major countries rate 
games and determine what we can learn from 
their practices. Rating authorities in the U.S., the 
U.K., Australia, and Germany discuss how they 
each make their decisions and what factors they 
deem particularly important. That makes this 
article a must-read for any developers who want 
to understand how games are treated by rating 
boards, as well as the amount of effort that 
actually goes into making sure that video games 
are geared toward the right audience. 

NEXT-GEN RELATIONS 

Our two other guest developer articles for this 
month focus on vastly differing, but equally 
fascinating areas of the game business. 

Former BioWare senior artist Rod Green 
presents a well thought-out feature on next- 
generation art pipelines, written from a technical 
art director's point of view (pg._19j. Is your art 
pipeline ready to deal with the massive amounts 
of extra data coursing through it as we segue into 
the next hardware generation? Green explains, 
both philosophically and practically, some of the 
most important points to bear in mind. 



Second, Mastiff's "head woof" Bill Swartz, an 
Activision Japan veteran, takes the opportunity in 
a Business Level column to muse on why many 
Western publishers and businesspeople are 
convinced that Japan is an entirely culturally 
alien landscape, and how this affects the way 
business gets done in the East. Swartz does a 
good job of explaining why we should listen 
carefully, look sharp, and in particular, hire a good 
interpreter, to avoid tragic loss of nuance. 

KAISER SOZE 

Elsewhere in the magazine, this month's art page, 
A Thousand Words, looks to Electronic Arts' From 
Russia With Love, replete with a suave Sean 
Connery and slinky new Bond girls. In addition, 
the Heads Up Display news section rounds up two 
important recent shows— the Austin Game 
Conference and Serious Games Summit— in case 
you missed out and would like to know what all 
the fuss is about. 

JACKSON VS. ANCEL 

Talking of fuss, a lot of the pre-Christmas critical 
interest we're seeing is focused on Ubisoft's Peter 
Jackson's King Kong. But there's something in here 
that's worth remarking on further. In recent 
interviews, Jackson has clearly outlined that he 
asked to work on the game with Ubisoft because 
of Michel Ancel's work on the earlier, under- 
exposed title Beyond Good & Evil. 

We needn't tell you why this is a great thing for 
video games— creators in other media wanting to 
work with individual creators for reasons of 
quality and meshing style, ratherthan wanting to 
work with companies and corporate entities for 
strict reasons of business is quite a step forward. 
Wonders will never cease. 

Hopefully, as particular game development 
teams delineate themselves in certain genres 
and with certain game styles, we'll see even 
more of this cherrypicking from film to game and 
game to film, since, well, doesn't it sound like it 
will actually result in better quality end 
products? Beating the movie license curse never 
seemed so simple. :•: 
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For every action in games there is an equal and opposite reaction. 

- Newton'sThird Law of PhysX 
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WHY CAN'T WE BE MORE LIKE SOUTH KOREA? 

That sentiment pretty much summarizes the hot 
talk at this year's Austin Games Conference. In 
addition to two days' worth of connected mini 
conferences on game writers and women in 
games, the main event was tightly themed to 

Lineage II turns a sizeable profit in Korea for 
developer NCsoft. 




cover massively multiplayer online games. 

The show contained four distinct tracks 
dedicated to MMOs: Online Business 8c 
Production, Online Multiplayer Design, Online 
Multiplayer Tech and Online Multiplayer Services 
and Support. Even the keynote addresses, 
delivered by John Smedley, president of Sony 
Online Entertainment, on the first day and Dr. 
Richard Bartle, teaching fellow at University of 

Essex and co-creator of 
the first MUD game, 
hummed alongto the 
pervasive MMO tune. 

Because online, 
persistent world games 
are not typically 
pressured into keeping 
step with next- 
generation technology— 
at least not to the 
degree that console 
games are— the 
sessions at the AGC 
tended toward 



business aspects of managingthe games, such as 
billing methodology. The few technological issues 
that were addressed by and large related to mobile 
connectivity only, or how to keep players 
connected to both their games and other players 
when not stationed in front of a computer. 

For MMO developers, a key field of study is the 
Korean market. Due almost entirely to cultural 
differences, online games thrive in Korea in a way 
that currently isn't recreated in North America or 
Europe. Nonetheless, the majority of speakers at 
the AGC ached to find some nugget from Asia that 
might translate into Western development tactics. 

"In Korea, we don't use retail because there is no 
retail channel. One of the things that drives the 
U.S. retail market is consoles. Until a year ago, 
consoles were illegal in Korea," explained Robert 
Garriott, CEO of NCsoft North America, whose 
LINEAGE series is enormously successful overseas. 
"In Korea, a retail channel will have to develop. In 
the U.S., just the way the markets have developed, 
retail is critical. Retail will continue to be critical." 

Yet to what extent retail is truly critical for 
western MMOGs' success remains unanswered. 
Hopefully, the Texas-based conference will 
address such questions in 2006. 

-Jill Duffy 



"I think there's a good chance prices 
[for MMOGs] will go up. $15 is not a 
price point. I don't think our player 
base is affected by the price. If it's 
a good game, they will pay $20. If 
it's a good game, they'll pay $25." 

—Robert Garriott, CEO, 
NCsoft North America 

"Innovation isn't really innovation 
unless it's intuitive and that's 
what we want from developers." 

—Paul Nakayama, producer, 
Amp'd Mobile 



"Why is your documentation so bad? 
... You push it off on the people who 
write 'Dummies' books. You push it 
off on the players. You push it off 
on the guys in customer support. 
Those of you who have MMOs, you 
have the opportunity to update 
your documentation every day. ... 
Put it in writing the way your game 
actually plays and not the way you 
wanted it to play three months 
before launch." 

—Steve Jackson, president and editor- 
in-chief of Steve Jackson Games, 
ranting about MMO developers' failure 
to write clear documentation 



"There's a difference between a 
game being for a subject matter 
expert and a game built for a 
person." 

—Jessica Mulligan, consultant 
( and former ASHERON'S CALL 
developer] on the barriers to 
attracting new players 

"It's not suits I object to, it's suits 
who call the creative shots." 

—Dr. Richard Dartle, teaching 
fellow at University of Essex and 
co-creator of the first MUD game 



"We don't need to charge [MMOG] 
customers subscriptions in order 
to make money." 

—John Smedley, president, 
Sony Online Entertainment 

"The big barrier [to making a profit 
from an MMOG] is subscription 
itself. We offer 40 to 80 hours of 
entertainment for $20 a month. 
You can't find a better rate for 
entertainment." 

—John Needham, CFO, 
Sony Online Entertainment 
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SGS GETS SERIOUS 



THE SERIOUS GAMES SUMMIT DX. 2005, WHICH FOCUSED ON GAMES 

created for training, health, government, military, education, and other 
uses, was held on October 31 and November 1, in Washington, D.C., at the 
Crystal Gateway Marriott, and attendee reactions and overall conference 
spirit seemed buoyant, as the nascent area of serious gaming continues 
to develop into essentially a sub-industry of its own. 

More than 70 sessions dealing with all facets of serious games were 
covered at the conference, and the keynotes were particularly diverse, 
with Peter Perla the Director for Interactive Research, Center for Naval 
Analyses, kicking off the conference with his look at the concept of 
"wargaming science." Perla, whom noted author and game designer 
Larry Bond has called "the leading wargaming expert in the United States" 
is the author of important reference tome The Art of Wargaming (Naval 
Institute Press). Perla started his lecture by noting that a colleague at the 
Naval War College, though a noted eccentric who suggested that the 
Department of Defense pursue research using pigeon brains as the basis 
of robotic control systems, had challenged Perla to write a second volume 
of his book, called The Science of Wargaming. This brought up an important 
point for Perla, as he recalled his internal response to this request: 
"Wargaming isn't a science— it's an art, it's a craft, but it's not a science." 

Perla went on to discuss possible ways that scientific concepts could 
be applied to wargaming, and then handed over to BreakAway Games 
CEO Doug Whatley, whose portion of the keynote concentrated on some 
of the practical problems of developing serious games. Whatley 
particularly took care to stress that those making serious games are 
game developers with sometimes confusing scheduling and naming 
processes, and it's important that those who are funding serious games 
"understand our process," in terms of scheduling and framework, 
sometimes especially alien for those working on government projects. 
However, Whatley suggested that the sky really is the limit in serious 
games, as he ended on a happy note, positively glowing about the possible 
future of the community, and evangelizing: "We can change the world." 

The second day's keynote presented a stark contrast to that of the 
first, with the animated, hyperkinetic Dr. Dave Warner, MD, Ph.D., who 
is the director of the Institute for Interventional Informatics and an 
expert in sharable situation awareness and real-time feedback on 

important events. The keynote 
description noted that Warner is 
"not a serious game developer, but 
his work on distributed 
intelligence, cutting edge sensor 
networks, and virtual reality 
makes him a shared partner in the 
quest to change the landscape of 
learning, healthcare, defense, and 
beyond." His intense, fascinating, 
and amusing talk, which touched on how to better solve real-life 
humanitarian and communication problems— and had definite 
relevancy to many of the problems of the serious games market— was 
enjoyed greatly by all present. 

The rest of Serious Games Summit (run by the CMP Game Group, as is 
Game Developer] was a whirlwind of diverse sessions, from the United 
Nations' discussion of its educational FOOD FORCE game, through Carnegie 
Mellon University and the New York Fire Department's talk on HAZMAT: 
HOTZONEand a multitude of other talks. You can read about a number of 
them in more detail atwww.gamasutra.com/sgsdc2005. 

— Simon Carless 
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The United Nations' FOOD FORCE 



IAWARP Q5I 

THE 2005 FRONT LINE AWARDS ARE UNDER WAY. A SELECT PANEL OF 

judges is diligently reviewing the products selected as finalists in the Front 
Line Awards, an annual evaluation of tools used in game development. The 
winning products, which are recognized for their excellence in helping 
game developers do their jobs better, more efficiently, and more 
gratifyingly, will be announced in the January 2006 issue. 

Game Developer congratulates the companies whose products were 
selected as finalists in the 2005 Front Line Awards. 



ART 

Zbrush 2, Pixologic 

FX Composer, Nvidia 

ClayTools system for 3DS Max 
(v.1.1) and Maya (vl.O), SensAble 
Technologies 

Modo 102, Luxology 

Maya ?, Alias (recently acquired 
by Autodesk) 

3D Studio Max 8, Autodesk 

AUDIO 

ISACT version 1.60, Creative Labs 

Miles Sound System, 
Rad Game Tools 

Lipsync SDK 3.0, Annosoft 

Harmony Hard Drive, 
DeWolfe Music 

CRIADX.CRI Middleware 

BOOKS 

GPU Gems 2, Matt Pharr (ed.), 
Addison-Wesley 

A Theory of Fun for Game Design, 
by Raph Koster, Paraglyph Press 

Audio for Games: Planning, Process, 
and Production, by Alexander 
Brandon, New Rider Press 

The Game Localization Handbook: 
Localization Production Pitfalls, 
by Heather Maxwell Chandler, 
Charles River Media 

Introduction to Game Development, 
Steven Rabin (ed.), Charles River 
Media 
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ENGINES 

Virtools Dev 3.0, Virtools 
Source, Valve 

Unreal Engine 3, Epic Games Inc. 

BigWorld MM0 Technology Suite 
V1.6, BigWorld Pty Ltd 

Gamebryo 2, Emergent 
Technologies 

HARDWARE 

Razer Copperhead, Razer 

Quadra FX 4500, Nvidia 

SpacePilot, 3Dconnexion 

MX40 Motion Capture System, Vicon 

DX1 Input System, Ergodex 

MIDDLEWARE 

SpeedTreeRT/vl.7, Interactive Data 
Visualization (IDV) 

Gameface, Anark 

AGEIA PhysXSDK, AGEIA 
Technologies 

Tira Jump Product Suite, Tira Wireless 
DemonWare Netcode, DemonWare 

PROGRAMMING 

Intel VTune Performance Analyzer, 
Intel Corporation 

Replay DIRECTOR v2.0, Replay 
Solutions 

Perforce SCM 2005, Perforce 
Software 

ProDG for PSRSN Systems 
SlickEdit 10, SlickEdit 
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OUR RATING SYSTEM: 



MEL SCRIPTING FOR 
MAYA ANIMATORS 



Second Edition 



BY TOM CARROLL AND KELBY FUCHS 



BOOK REVIEW 



INNOVATOR DALE DAUTEN ONCE 

said, "It's time to re-appreciate 
the original software: paper." 

This leads us to a discussion of 
the ups (many) and the downs 
(few) of the second edition of 
MEL Scripting for Maya 
Animators, a 529-page stack of 
"original software," so to speak. 
Written by Mark R. Wilkins and 
Chris Kazmier, this new edition 
is— as was the first edition— the 
very best of an extremely small 
number of books that even 
attempt to cover the subject of 
scripting animation. 

For those who may be new to 
the field, MEL, which stands for 
Maya Embedded Language, is the 
scripting language used within 
Maya. MEL allows the user to 
automate any operation that can be 
accomplished through Maya's GUI; some 
of those operations can be extended 
through MEL in ways that aren't possible 
using the GUI alone. 

This review looks at Wilkins and 
Kazmier's book in two takes. 



TOM CARROLL 

While I aspire to be a Maya technical 
artist, I am certainly not there yet. 
Because I have a day job that doesn't 
require me to use Maya deeply and 
daily, and because I have a family, my 
day-to-day exposure to MEL scripting is 
limited. Picking up the second edition of 
MEL Scripting, however, allowed me to 
see how far I could push myself in a 
relatively short period of time— about 
three weeks. As they say, the results 
were heartening. 

I never used the first edition of this 
book (though my co-author did), so my 
impressions are limited to the updated 
version. Luckily for a neophyte like me, 
the book starts out with an explanation of 
the basics. Wilkins and Kazmier have 
built a foundation for a broad audience, 
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and the first brick is the admission that 
Maya works very hard to hide much of 
what's "going on under the hood" from 
the casual user. 

The authors take great pains to explain 
where pertinent features, graphs, and 
editors are found, and to paint a picture 
of the interconnectivity of Maya's 
various networked nodes. The average 
Maya modeler or animator knows this 
about as well as an amateur astronomer 
knows the dark side of the moon. 
Wilkins and Kazmier also explain that 
some aspects of Maya can't even be 
manipulated at all unless they are 
accessed through scripting. 

By the end of Chapter 1 ("Maya Under 
the Hood"), I was fairly comfortable with 
the authors' approach. The style is 
inclusive. The authors stop to clarify 
specialized terminology, and the written 
word is supplemented from time to time 
with appropriate figures. 

READER ENGAGEMENT 

Specific exercises, which the reader is 
expected to complete, are included to 
augment what the authors are teaching. 



These exercises are outlined in clear 
language, step by step, usually with one 
ortwo accompanying visuals to help 
ensure the reader is achieving the 
desired results. 

By the time I reached Chapter 3 ("Using 
Expressions"), I was ready for more 
substantial exercises. I had already built 
a foundation for my MEL learningthat 
would permit me to systematically add 
knowledge: the location and function of 
the Command Line, the Command Shell, 
and the Script Editor; how to create a MEL 
script, run it, and verify the result(s); and 
how to capture MEL commands from the 
interface and add them to my existing 
scripts. Chapter 3 expanded this 
knowledge by introducing the concept of 
expressions (an expression is a script 
that calculates values for one or more 
attributes in the scene). "Example 1: 
Eyes" then showed how to use an 
expression to determine whether a pair 
of eyes tracks an object in a coordinated 
or uncoordinated way, and another 
expression to make the pupils of those 
eyes dilate or constrict in relation to an 
outside variable (in this case, light). 

As with the other examples, this one 
was very well thought out. It was 
designed to teach specifics as a means 
to open up a wider world of general 
principles. In fact, one of the more 
successful aspects of using this book is 
that it helps you to learn (or re-learn) 
about Maya in a bigger, more diverse way 
than you may have before. 

KELBY FUCHS 

I have been creating video games for 
more than seven years as a technical 
artist, and I've always enjoyed helping 
others get a handle on new software, 
asset pipelines, and improved workflow 
techniques. I don't have a computer 
science degree, but I did take a MEL 
scripting course in college. Luckily, 
during my college years, paired with a 
buddy from computer science who 
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SKUNK WORKS 



excelled in programming, I was able to 
get a grip on complex terminology as well 
as some of the core concepts that I would 
need to carry with me into my career. 

My copy of the first edition of MEL 
Scripting is now a mass of dog-eared 
pages, copiously highlighted and 
enveloped in sticky notes. The book was 
a major stepping-stone into the world of 
scripting for me. With very clear 
explanations of programming concepts 
and easy-to-follow examples, it has 
remained within arms' reach. 

I found the concepts of global and local 
variables and procedures extremely 
helpful. Issues of scope within scripts 
created hindrances for me initially, but I 
can now use them to my advantage. 

The new second edition embellishes 
on the first book in many ways and 
includes new sections for fixing 
programming bottlenecks and additions 
to the user interface. It quickly gets you 



into how Maya works and the many 
features and actions you have control 
over. The authors frame this technical 
material with handles most artists 
should be able to grasp. 

This book is filled with great examples 
of simple procedures that even a 
scripting lightweight can comprehend. 
It's helpful to read through the preface to 
understand whom the specific chapters 
are directed toward. 

For instance, the section in Chapter 3 
that asks the reader to set up eyes to 
focus on one object or two uncoordinatedly 
was fun because it got me thinking of 
some other complex rig configurations 
that I could make. Also, setting up simple 
particle expressions to control particle 
flow in Chapter 5 ("Problem Solving with 
MEL Scripting") gave me a sense of the 
amount of control and ability to automate 
complex repetitive tasks I can now take 
advantage of in a routine manner. 
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XOREAX 



SYNTACTIC MATTERS 

Though syntax is explained in 
Chapter 3, 1 would like to see a 
reference chart that listed 
simple examples and complex 
commands. Maya syntax can 
be very challenging because 
the order can vary in form 
when written in an expression 
as opposed to a MEL script. For 
beginners, deciphering the 
proper use of syntax is often 
difficult to grasp. A few pages 
dedicated to the format of 
allowed words, special 
characters, and structure of 
MEL commands with the 
appropriate parameters in the 
correct order would help 
novices tremendously. 

For instance: when should { } 
be used instead of () or []? 
Also, why is Maya so picky 
about the direction of a slash, 
like backslash as opposed to 
forward slash, when dealing 
with texture or reference 
paths? And most important is 
the use of backtick versus a 
single quote mark when 
storing command results into a 
string (for example, string 
$sphereName= % sphere' ). 
A reference page would be 



helpful as new users encounter the 
inevitable// Error: line #: Syntax Error// 
that's so frustrating to interpret. 

Many of the teaching examples use 
particles, which can be fun to play with. 
For instance, Chapter 5 has an example 
that shows how to automate setup for 
Spiral Particles. It makes it easy to see 
how MEL can greatly increase your 
productivity. Chapter 14 ("Custom Dialog 
Boxes") has another example in which 
you create a window interface to control 
your script or parameters. What animator 
doesn't want to make a control interface 
of his or her own? While the book's 
dependence on particles for some 
examples was fun and productive, it's 
important to remember that, at least in 
my experience, particles for games are 
often generated with tools developed 
outside of Maya. 

BEST USE 

While MEL Scripting is an excellent 
resource, I find it a little difficult to use 
like a desk reference. It might help if 
there were a robust cross-reference 
section that listed terminology common 
to the field even if not specifically used 
in this book. 

If you have the first edition of MEL 
Scripting for Maya Animators, you 
might not need to purchase the second 
unless you're fluent in scripting and 
specifically need help with optimizing 
character rigs, fixing programming 
bottlenecks, or advanced user interface 
techniques. If you're just getting 
started or are advanced enough to want 
the second edition's beefed up content, 
there's an empty spot for this book next 
to your monitor right now. But make 
sure there is enough space for a few 
pads of sticky notes and a couple of 
highlighting markers. You'll want to ink 
this one up. :•: 

TOM CARROLL is an environment artist. 
KELBY F U C H S is a technical artist. 
Both work for Rockstar San Diego. Email 
them at tcarroll@gdmag.com and 
kfuchs@gdmag.com. 
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WHERE GAME RATING 
BOARDS DIFFER 




THE RECENT CONTROVERSY OVER THE HOT COFFEE MOD FOR 

Rockstar's Grand Theft Auto: San Andreas, and its subsequent 
temporary re-rating by the ESRB from M (mature) to AO (adults 
only) has only intensified the focus on howvideo games are 
rated in the U.S. But in the British Isles, as we'll discover, game 
raters scratched their heads and wondered what all the fuss 
was about. This fact alone showcases the cultural and 
procedural game ratings system differences among different 
territories of the world. 

We at Game Developer investigated and tried to compare the 
video game rating systems of four countries— the U.S., the U.K., 
Germany, and Australia. Each territory deals with games in a 
slightly different way, both in terms of how they are screened 
and how the government or voluntary bodies combine to allow 
the rating of titles, making for some fascinating comparison 
points. There's no empirical right or wrong when it comes to 
game rating— just the seldom-raised opportunity to look at 
multiple data points, and see how different territories hope to 
rate and compare vastly differing gameplay experiences for 
countries and people that are culturally different. 

FULL DISCLOSURE, U.S.A. 

The New York City-based Entertainment Software Rating Board 
(ESRB), a self-regulatory body established by the 
Entertainment Software Association trade organization in 1994, 



issues a rating to more than 1,000 games each year, a 
formidable task to be sure. That's practically every video game 
released to retail in the U.S. minus a few sold strictly online. 
Because of this volume, and the fact that games can sometimes 
take tens of hours to beat, the ESRB doesn't attempt to play the 
games all the way through in order to determine their content. 

"We depend on full disclosure of all pertinent content by 
the games' publishers," says Patricia Vance, the ESRB's 
president, "and that's done through an extensive written 
questionnaire that documents everything that's relevant to 
our rating system." 

"Pertinent content" isn't the easiest concept to get one's head 
around, but it can mean, for example, not only the degree of 
violence of an act but also how much control the player has over 
that violence. In other words, after shooting a character, can the 
player continue to shoot that person after he or she is dead? 
And what is the effect if the player continues to shoot? Such 
details, which the ESRB says are totally pertinent to the overall 
intensity of the experience, are covered by the organization's 
lengthy questionnaire. 

"We are actually quite specific about what we mean by 
'pertinent content' in our submission materials," Vance notes. 
"Even if you were to interpret 'pertinent' differently than we do, 
it would be hard to misinterpret it when you're filling out the 
submission forms. We also include information about how to 
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review content and how to prepare it for submission. If 
publishers still have questions, there's contact information on 
our web site to reach the people in our ratings department with 
whom they're probably already familiar." 

In addition to the questionnaires, the ESRB expects to receive 
lyric sheets and highlighted scripts, if appropriate, along with 
videos that give a good idea of the game's context, story line, 
objectives, mission, options, typical gameplay, and especially, 
the most extreme violence, language, suggestiveness, and 
sexual content. 

While Hollywood raters have the luxury of viewing completed 
movies, the ESRB does its job while the developers continue to 
remove bugs, link missions, and spiff up the final product. So, if 
the board believes it needs more information about a game, it 
will sometimes request a build of the title in its current state so 
that its staff can further evaluate the game in question. 

Once the submission is deemed complete, the ESRB draws 
from its pool of part-time, independent adult raters who have no 
other ties to the industry but are willing to work two orthree 
hours per week viewing content. Based on the feedback of at 
least three raters— but sometimes as many as nine— the ESRB 
looks for a consensus upon which to base its final rating. 

Critics point out that it would be easy for publishers to fudge 
their submissions, perhaps leaving out references to violence in 
order to earn a less severe rating. But the ESRB holds firm (with 
consequences) that there's no incentive whatsoever to such 
shenanigans. If offensive portions of a game are discovered 
after it ships, the ESRB requires publishers to have the game re- 
rated, re-stickered, possibly recalled, with all advertising 
changed appropriately. 

"It's extremely costly for a company to do that," Vance notes. 
"Not only are the corrective actions expensive, but there may 
also be penalties and fines associated with nondisclosure." 

The ESRB has modified those ratings overthe years, adding 
descriptors to better help consumers understand the rating 
system, and makingthe ratings and descriptors more 
prominent on the game boxes. Most recently, a new rating— E 
10+, for everyone 10 and older— was added "because we felt 



that consumers, particularly the under-14-year-olds, were 
demanding a new category for those in-between years. And 
there was plenty of product that met those requirements, 
meaning not suitable for age 6 but not yet at the T rating [for 
everyone 13 and older]," says Vance. "Our goal is to keep the 
system current." 

Vance acknowledges that the next generation of game 
consoles and more advanced technology will definitely change 
the face of the industry, thereby affecting the ratings system. "I 
certainly think the online environment is a challenging one for 
us," she notes, "especially when gamers can generate their 
own content, say, through mods. That's an area where parents 
need to be more vigilant, and one that I'm not so sure we can 
do much about." 

Developers have queried the rating system on occasion, 
saying that there is a place for mature games, but that large 
retailers refuse to sell anything with an AO (for 18 years and 
older) rating. Vance, however, believes that what happens in the 
marketplace should not be blamed on the ESRB, refusingto let 
herself or the organization be held responsible for such outcomes. 

"That's the marketplace making up its own mind, not us. We're 
just here to accurately label product. If retailers choose not to 
sell AO product for whatever reasons— because they don't think 
it will sell, or they don't think their customers want them to 
carry it, or it doesn't fit in with their family-friendly image— 
that's their decision. Not ours." 

VOLUNTARY AND GOVERNMENTAL, U.K. 

In 1993, one year before the birth of the ESRB, the U.K.'s 
Entertainment Leisure Software Publishers Association (ELSPA) 
and the Video Standards Council (VSC) created the ELSPA 
system, which makes it necessary for all ELSPA members to 
submit their games for ratings. Just as in the U.S., it's a 
voluntary system which is enforced by most video game 
retailers who won't sell un-rated games. 

Laurie Hall is secretary-general of the VSC, the standards body 
that administers the ELSPA system and represents the 
country's game publishers as well as more than 10,000 retail 
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outlets. Between 1994 and 2003, Hall and his team have rated 
well over 7,000 games. 

As with the ESRB system, the VSC depends on "the help and 
guidance of the game publishers who answer a series of 
questions which then throws up an age rating," says Hall. "So 
far, we haven't had any examples of abuse or anyone 
deliberately hiding things from us." 

The games that receive the most mature ratings— for ages 15 
and up and for 18 and up— are examined by the VSC before 
those ratings are applied. "That's to make sure that the game 
has been rated correctly at that higher, more sensitive level," 
Hall notes. 

Unlike at the ESRB, the VSC uses professional raters who 
examine the games in detail using cheat codes provided by the 
publishers. Their typical workload is approximately 200 games 
annually. 

"What they are looking for is to make sure that the game 
hasn't crossed the line from being in the voluntary category to 
the mandatory category where the game needs to be submitted 
to the British Board of Film Classification (BBFC)," explains Hall; 
or, as stated on VSC's web site [ www.videostandards.org.uk] : 
"Before a game can be rated under the voluntary system, it 
must be established that the game is exempt from legal 
classification in the U.K." 

According to British law, games containing gross violence 
and/or sexual content need to be submitted to the BBFC, a 
government body, for legal age classification. Only two or three 
percent of the games published— so-called "extreme games"— 
receive this treatment. In fact, the ELSPA system was developed 
specifically to deal with the overwhelming majority of games 
that would otherwise have had no rating at all. 

"The penalties are quite draconian for a game publisher or 
retailer getting it wrong and selling a game that should have 
gone to the BBFC but didn't," Hall warns. "Under the law, the fine 
can be unlimited, plus up to six months in jail. And so, everyone 
tends to follow the rules. It tends to concentrate the mind." 

In 2001, the Interactive Software Federation of Europe (ISFE) 
met in Brussels to tackle the issue of the growing number of 



national rating systems. At the time, there were already four 
rating systems in Europe, and the ISFE feared that confusion 
would erupt if every country created its own system. 

"You can imagine what a game box would look like if it needed 
to carry 10 or 15 different age ratings on it," says Hall. The ISFE's 
solution was the Pan-European Game Information System 
(PEGI), a single video game rating system that is now 
administered by both the U.K.'s VSC and The Netherlands 
Institute forthe Classification of Audiovisual Media. The number 
of countries using the system has grown from 16 to 20, with the 
notable exception of Germany. 

"There had been a shooting in a school there and, just as in the 
U.S., a computer game was blamed," explains Hall. "Legislation 
was passed that all video games in Germany had to be rated by 
their government, which is still the case." 

As with the ELSPA system, any game publisher requesting a 
16+ or an 18+ rating must have its game examined before it 
gets rated. Games self-rated for ages 3, ?, and 12+ are examined 
retrospectively. 

While the PEGI members agreed on how they would rate 
games, there will probably never be agreement on what is 
objectionable and what isn't in the various member countries. 
For instance, the U.K. seems particularly concerned about bad 
language, more so than on the continent, but sexual content 
gets just a middling reaction, which is still more than in the 
Scandinavian countries which are extremely liberal in that 
regard. But when it comes to violence, the U.K. and other 
southern European countries are fairly accepting of it in their 
games, whereas Scandinavia is much more restrictive. The 
solution has been the use of "descriptors" on packaging. If a 
game gets an age 16 rating because of language, a mother in 
the U.K. who sees the "language descriptor" might prevent her 
child from buying it, but a mother in France, who isn't 
particularly bothered by such language, may have no 
hesitations about buying it for her 12-year-old. 

"The same sort of cultural differences popped up with the so- 
called Hot Coffee issue with GTA," recalls Hall. "I know the scene 
depicting a sex act caused a great stir in America. Even Hillary 
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Clinton got involved. But we looked at it and it seemed relatively 
trivial. Did we change the rating? No, because it was already 
rated 18 for violence, which is the highest it can go. Would we 
have raised it if we could? I think not; as I said, that sort of thing 
is considered mild over here." 

UNDER GOVERNMENT 
SCRUTINY, AUSTRALIA 

There's no such thing as a voluntary video game rating system 
in Australia. Under national law, no video game can be sold or 
rented unless it has been rated by the Classification Board 
(formally known as The Office of Film & Literature 
Classification), an independent statutory authority. 

Australia applies a comparatively simple system containing 
just four ratings or "classifications:" General (G) for very mild 
content, Parental Guidance Recommended (PG) for mild content, 
Recommended for Mature Audiences (M) for moderate content, 
and Not Suitable For People Under 15 (MA15+) for strong content. 

Although films can be rated as R18+, any game with content 
strongerthan an MA15+ is simply refused classification and 
cannot be sold or rented in Australia. What usually happens is 
that publishers modify these titles for the Australian market in 
order to receive an MA15+ rating. 

After paying a fee, publishers provide a "comprehensive and 
detailed synopsis and description of gameplay sufficient to 
allow the Board to work its way through the entire game if it 
needs to," says Des Clark, director of the Classification Board. If 
the game contains content that is likely to receive an M or 
MA15+ rating, that content must be provided on videotape or 
demonstrated to the Board by the publisher. 

"The recorded or demonstrated sequences of M or MA15+ 
content are given very close scrutiny, as is the content of G 
and PG games," adds Clark. "As the Australian government is 
committed to protecting children from things that may harm 
them, we take classification of games at all levels extremely 
seriously." 

Ratings are based on an "impact test"— from very mild impact 
to strong impact— for each of several classifiable elements, 



includingthemes, violence, sex, language, drug use, and nudity. 

"The impact test means that we need to consider not only the 
impact of the individual elements but also the cumulative 
impact of the overall production," says Clark. 

The review board can contain as many as 20 people who have 
20 working days to create a report that outlines their decisions. 
The publisher is then given a classification certificate plus a 
copy of the report, if requested. 

"In my opinion, the fact that Board members are recruited to 
be broadly representative of the Australian community ... and 
the fact that the mechanisms by which classification decisions 
are made are clearly laid out in legal instruments contribute 
very strongly to the success of our system," says Clark. 

Because the Board rates not only video games but also 
movies, DVDs, and videos, its biggest challenge these days is to 
deal with the increasing volume of content being released onto 
the Australian market. The solution has been twofold: to 
increase the size of the Board itself and to create so-called 
authorized assessors. 

The assessors are employees of publishers who are trained by 
the government to review the games themselves and make 
recommendations to the Board in comprehensive reports for 
games they believe deserve G, PG, or M classifications. In 
addition, they must supply the M content to the Board either on 
videotape or through some other means. The Board reads the 
report and either accepts the recommended rating, calls for 
more information, or repeats the classification process. Members 
of the board must view and classify MA15+ games themselves. 

Occasionally, the Board plays the games up for review in their 
entirety, but not often. "Due to the massive volume of content in 
many games, it's usually not possible," Clark explains. 
"Government policy requires the cost of classification services 
to be recovered from applicants. Because of the time it would 
take, if the Board were to play every game through, the cost 
burden on applicants would be huge, not to mention the 
potential for delays." 

That means the system relies on applicants to submit complete 
information, which, in Australia, is their legal obligation. 
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"If they do not ... if content is found [afterthe game's release] 
to be at the M or MA15+ level and would, therefore, cause a 
higher classification, the Board revokes the game's certification," 
warns Clark. "That is what happened here with the Hot Coffee 
modification of Grand Theft Auto: San Andreas. So it is extremely 
important that the Australian distributors are made aware of all 
content by the developers so it can be provided to the Board." 

EXTREME VIOLENCE IS 
VERBOTEN, GERMANY 

The two-year-old German Juvenile Protecting Law states that 
every video game must have an age rating on it, or it can only 
be sold to adults. Unlike in the U.S., adult games (with M and A 
ratings) seem to have no stigma attached to them since they 
are readily available for purchase by adults at German retailers. 
That is, unless they have been banned completely, likely due 
to excessive violence, or use of forbidden symbols, such as 
the swastika. 

"Developers can create any game they want to, just as long as 
they take into consideration that there is a rating system for the 
protection of minors," says Jurgen Hilse. Hilse is the Permanent 
Representative of the Supreme Youth Authorities of the Lander 
at the USK (Unterhaltungssoftware Selfstkontrolle), Germany's 
software rating body. 

Within the USK, between three and five "video game experts" 
from a board of 52 are randomly selected to review each 
submission by a publisher. The process involves a discussion of 
all aspects of the game, including graphics, contents, gameplay, 
and other topics that would be relevant in selecting an age rating. 

"The main focus is this: Are there any elements in this 
computer game that would possibly have a negative impact on 
juveniles of a certain age?" says Hilse. "If the board of experts is 
convinced that there are risks for a certain age, they rate the 
game up to the next age category." Criteria for all age ratings are 
listed on the USK's web site, though the text is in German. 

Hilse prides himself on the fact that the USK board handed out 
almost 2,500 ratings last year, usually within 14 working days, 
if all the appropriate information was submitted properly. In 



order to accomplish this, the board employs three full-time 
game testers who are tasked with playing the entire game 
through using cheats and walkthroughs supplied by publishers. 
Using "save game" options, they construct a presentation to the 
board of experts. 

"These testers must be video game experts with a lot of 
experience," Hilse explains, "and, of course, they have to be very 
reliable so that the board is convinced it has all the information 
it needs to make a proper age rating." 

Hilse says he finds the different views that various countries 
have about the harmful effects of video games interesting. 

"In America, sex and bad language seems to be the focus of 
discussion and, in the case of the Hot Coffee mod and Grand 
Theft Auto: San Andreas, the wrong content can mean enormous 
financial loss for a publisher," he notes. "Here in Germany, 
violence dominates our concerns, and too much violence can 
get a video game banned." 

MIDDLEMAN'S STIGMA 

Regardless which country is monitoring the classifications, the 
raters are unanimous in their advice to game developers and 
publishers: "Remember, we're on your side!" 

"I know they'd much rather not have to deal with us at all," 
says ELSPA's Laurie Hall, "but we're not the enemy. We are here 
to make sure they satisfy consumer, retailer, and legal 
requirements." 

The ESRB's Pat Vance stresses that the submission process 
ought to be taken very seriously. "We're here to protect the 
publishers and developers as much as we're here to inform their 
customers," she stresses. "This is not an adversarial 
relationship, although I often think developers consider us to be 
their adversary. We're not. We're here to make sure that the 
content they create is accurately labeled ... so that everyone 
doesn't find themselves in a situation where there are 
consumer complaints or where there are surprises that take 
everybody— including the publishers and developers— down 
with them." :•: 
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■ DEVELOPERS WORKING ON THE NEXT GENERATION OF GAMES 

have some significant concerns about the ability of existing art 
pipelines to handle their growing production needs. The number of 
artists involved in a project is swelling as high as three figures, and 
the amount of data handled in a game is growing into terabytes. 

The core of the problem is the expanding number of artists 
needed to achieve a constantly rising standard of detail. With 
any increase in detail, there is a corresponding increase in the 
nature and number of technical hurdles during development. 
The trick is to be as efficient as possible with the flow of 
information between artists and the tools they use. It's an issue 
I've been addressing for companies with next-generation art 
needs, such as BioWare. 



ART PIPELINE ASSESSMENT 

The goal of any art pipeline— the interconnecting software, 
utilities, processors, and techniques that artists use to design, 
develop, and submit assets— should always be to make sure 
the artists on the project are able to work as quickly and 
efficiently as possible. 
A good pipeline should have the following core features: 

• fast art iteration 

• detailed art tracking 

• detailed feedback 

• common data formats 

• a modular structure with a centralized hub 

• robustness. 
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FIGURE 1 Atypical export 
pipeline. 



When defining a pipeline, it's best to start with 
the big picture and then drill down to the specific 
areas that require more definition. In general 
terms, all assets go through three major stages: 

• design 

• creation (which includes the feedback and revision loop) 

• submission. 

Each stage is made up of two key components: asset creation 
tools and asset processing tools. The technical art director must 
carefully define the data flows (export, import, copy, move, 
archive, check in, check out) and the types of data you 
anticipate will move through them (such as textures, meshes, 
animation, hierarchies, materials) before setting up this flow. 
The thing to most carefully avoid is a back step because of a 
deficiency in the pipeline. 

THIRD-PARTY ART TOOLS 

Picking the right tool for the job. There are two major pitfalls that 
you should try to avoid when picking software to incorporate 
into your pipeline. First, don't rely on a magic bullet approach 
when it comes to art tools. Pick a tool that fulfills as many needs 
as possible, but recognize that it won't be able to do everything. 
Trying to bend one tool to fit all your needs can cause more 
trouble than it's worth. 

Second, when planning, many teams apathetically "stick with 
the devil they know" rather than evaluate new tools. Many studios 
are well aware that the software suite or version they use is 
substandard, but they stick with it anyway out of fear that they'd 
have to retrain everyone or that all their tools are built into version 
X, or that X software vendor is their friend. Or, they simply might 
not take the time to reevaluate the pipeline between projects. 

If one of your vital tools is substandard, start working out a 



plan to implement a replacement or updated version. Your 
pipeline needs to be future-proofed, as much as possible 
anyway, meaning you should build your art pipeline in a way 
that best prepares it for future integrations and updates, without 
having to rewrite all your art tools every time a change is made. 

Make sure everyone on the team, including the art tools 
programmers, evaluates all available tools and their support 
network before you decide to purchase a new tool. That includes 
considering tools that might not be conventional. Zbrush is a 
great example of a tool that was created for one purpose, but as 
a by-product, was found to perform other tasks very well and 
became an integral part of many pipelines practically overnight. 

As projects progress, there will be points where new solutions 
are necessary. If the pipeline is set up well, it can limit the time 
it takes to add new features. For example, the character 
animators on a project are working in art package X with the 
modelers, but they discover that art package X's animation 
systems weren't able to support the animators effectively, 
thereby reducingtheir productivity. The obvious solution would 
be to find another tool to support the animators. 

In a typical pipeline, the character exporter (rig and animation) 
would export from X into one CHR file (see Figure 1). But this 
would mean that the animation from the new tool needs to be 
exported to X, then again exported by the modelers with their rig. 
However, if the exporter were split into the separate components, 
namely RIG and ANI files (see Figure 2), then all you'd need is an 
animation exporter for the new tool. Then, the modelers and 
animators can export independently of each other. This would 
also mean that, if art package X were found to be less appropriate 
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FIGURE 2 An alternative export model. 



for modeling at a later date, 
replacing it would have little to no 
effect on the animators. 

Art data formats. Every tool has 
its own custom format for storing 
data, along with a varying array 
of more universally-supported 
data formats. Some software 
companies are very protective 
and actively make it difficult to 
use other formats, which can lead 
to bad or broken exporters and 
unnecessary data loss; it can 
even render files from newer 
versions incompatible, locking you into a vicious cycle of 
needing to upgrade frequently and across the board. 

Generally, the more ways a package can export data, the 
better. With any package that has an SDK or a scripting host, 
such as XSI or Maya, a tools programmer or technical artist can 
usually extract the data from the software into any format 
needed. However, this can be quite difficult if the package 
doesn't give the user access to the data needed. Take a look at 
Photoshop. If it had initially been restricted to only handling 
.PSD and JPG files, it would never have become as popular as it 
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has, despite how usable and powerful it is. Therefore, try to pick 
tools that are as open as possible. It'll help you in the long term. 

In-house art tools. All development processes suffer from 
various problems, but if your problems are caused by an 
inefficient or defective third-party tool (or a task for which no tool 
yet exists), then the art tools team needs to create an in-house 
tool. From my perspective as a technical art director, the 
following steps are vital when considering in-house tool creation. 

First, be clear about what the tool will do. Typically, building a new 
tool requires a staged development process, and therefore, the 
technical art director should have separate "first implementation" 
and "ultimate aim" targets for the tool. The first implementation 
defines the minimum functions to start implementation: rollout and 
shakedown. The ultimate aim is the goal forthe long-term 
development of the tool— when is it considered complete? The art 
tools team will then decide where exactly in the pipeline the tool is 
goingto sit. You will also need to consider whether it will be 
integrated into existing software in the pipeline (script, plug-in) or 
become a whole separate step in the pipe. 

There are advantages and disadvantages to implementing a 
tool directly into another piece of software either through 
scripting orthe SDK, as explained in the sidebar (see Tool 
Implementation, pag e 23) . 
However, there are of course different levels of software 

integration. For instance, you could integrate 
just the Ul, but not the core system, thereby 
getting the advantages of being integrated 
without the dependency on the software. 
However, the Ul would then need to be re- 
written if the tool is changed. 

The most powerful and robust tools need to sit 
on the same layer as other tools of similar 
function. Generally, keeping a tool abstracted 
from third-party packages allows you to better 
control the flow of data and provides more 
universal access to that new tool (see Figure 3). 

MODULAR STRUCTURE, 
CENTRALIZED HUB 

Regardless of whetherthe tool is integrated or 
kept as an external application, every tool 
should be made to be as modular as possible, 
interconnecting through a central interface. 
When creating a tool, try to create it with the 



FIGURE 3 Contrasting different pipeline layers. 
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mindset that it is an independent module that receives and 
sends data. That way, if any tool needs to be refactored, then 
you only need to make sure the input and output plugs stay 
intact, and the internals of the tool can be changed completely. 

However, this is not always possible when a change needs to 
be made to how a tool receives and sends data. In this case, 
you'd also need to rework the plugs. This shouldn't be a problem 
if you're careful when planning your data formats. The 
centralized hub will allow the user to edit and tweak many 
different aspects of the asset— from animation, materials, and 
visual effects, to sound queues— in one suite of tools. 

A centralized hub doesn't mean, however, that a module can 
only exist in connection with this hub. As stated previously, 
each module needs to be independent so it can be integrated 
into another tool (such as a third-party application), or so that it 
is able to run completely without direct user input, which makes 
it automated and thus a viable component in any kind of batch 
processor system. A modular system, if done right, also cuts 
down on code duplication by allowing you to easily share tools, 
functions, and processors with all applications in your pipeline. 

INTERFACE AND 
PROTOTYPE DEVELOPMENT 

As a designer of a tool, it's a good idea to work with the artists 
who are going to be using the tool in order to create a prototype 
of the interface and workflow. The artists should also take 
ownership of how the tool works, judging how intuitive it is to 
use. On their own, tools programmers might create a tool that's 
efficient and functional, but also completely unusable for an 
artist. A tool's interface can be created by a technical artist in a 
relatively simple visual coding package, such as C# or even 
HTML, where the workflow can be shelled out and used as a 
visual template for the programmer to create the actual tool. 

Doto formats. Make sure you work out where data is going to 
and from the tool first and then decide how this data is going to 
be represented in the file. The format should be extendable to 
allow for additions to the format in the future, and stable. If data 
is missing or incorrect, the importers and exporters should be 
able to safely skip the problematic chunk and 
keep going. 

In all development stages of the pipeline, if 
any data is missing, the tools need to fail 
gracefully. An engine that crashes without 
detailed, informative feedback because of a 
missing secondary resource (textures, sound 
files, or sub nodes, for example) is going to 
seriously slow down early development. The 
feedback should give a clear indication of what 
resource caused the problem, such as the 
descriptive "model 'aModel' resource 
'aTexture.tga' failed to load!" and not something 
generic like, "missing resource!" 

It's also a good idea to unify all your tools to 
support one proprietary format so that you 
only need to manage one set of file writers and 
readers. Also, try to keep the data as open as 
possible. ASCII is great for this but can be very 
slow for reading and writing. Using a binary 
format is fine, as long as there are very good 
editors and inspectors for the format. 

Shakedown. When developing proprietary 




tools, allow adequate time for shakedown. Don't expect that the 
tool will be fully functional the first time it's released to the art 
team. It will have bugs, it will need adjustments to the Ul, and it 
will require additional features. If you skip the shakedown step 
and force a tool into full development too early, then you risk 
burning your users, frustrating them with obvious problems to 
the point that they become reluctant to provide feedback on 
genuine unknown issues. 

Update mechanisms. Many companies overlook the inclusion 
of an update mechanism for the tools they create. But it's a 
good idea to create one automatic mechanism for all art tools so 
that everything becomes synchronized, thereby providing 
everyone on the team with the latest versions of the tools at the 
same time. If you do this and allowthe update mechanism itself 
to become part of the art pipeline, you should also consider 
allocating resources to develop and support it. 

DATA FLOW FOR NEXT-GEN ASSETS 

Tracking. In working with next-generation assets, you need a 
system that lets you monitor the progress of an asset through 
to completion, as well as link to the feedback given during 
development. This system should also keep a list of links to 
reference and source material, such as high-resolution meshes, 
concept artwork, books, and web sites— a bibliography for the 
assets. The bibliography could be built into your asset library 
system or attached to a customized bug tracker package. 

Processing. At different stages in the pipeline, there will be 
tools that change (or process) the input data before passing it 
onto the next step such as an animation optimizer. This is 
typically some kind of refining or formatting step, which often 
results in a redundant asset. 

Redundancy. When an asset gets processed in the pipeline, 
the asset typically becomes redundant. The process of 
collapsing layers of a .PSD in Photoshop is a good example. The 
.PSD file is the source art and the collapsed image is a 
processed version. You want to make sure that the pipeline 
doesn't mix up redundant post-processed data with source data. 
The best way to achieve this is to use two separate formats for 



tool implementatior 



There are advantages and disadvantages to implementing a tool directly into another piece 
of software, whether through scripting or the SDK. 



ADVANTAGES 

1. Fast tool development time. You have access to the 
tools' existing systems— animation, mesh, painting, 
and Ul controls. This means, as a tools developer, you 
can just plug into these systems and create a functional 
tool very quickly. 

2. Fast communication turnaround. If the artists on the 
project are already working with this tool, there doesn't 
need to be any exporting or importing to slow them down. 

3. One package. The artists only have to worry about 
using a single piece of software. If the tool's interface 
is external to the main package, then the artists 
might need to switch to that tool, which could 
potentially slow them down. 



DISADVANTAGES 

1. Software dependent. If there is a need to upgrade or 
change the underlying package, then the art tools team 
will have to consider refactoring or rewriting the tool. 

2. Limited by the package. The SDK or the scripting host 
might not expose enough of the information needed or 
may become slow because of inefficient underlying 
code that can't be changed. 

3. Limited accessibility for external tools. When 
integrating a tool into another piece of software, 
you're restricted by the accessibility that software 
allows. If the tool is external you have complete 
control to access that tool without having to 
establish a connection to a host program. 
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each type, such as .PSD (layered and high 
resolution) and filetypeX (flattened, down 
sampled and compressed). If you decide to use 
one common format, then you'll need to make 
sure the processed files are kept away from the 
location of the source files. In a manual process, 
the file-saving location is at the discretion of the 
artists. However, if you support the source file 
type in your art tools and do the processing step 
automatically behind the scenes, then the artist 
won't ever get the source and processed files 
mixed together. All they work with and see are 
the source files; the rest of the pipeline deals 
with only the processed files. 

Submission. When an asset is submitted into 
any queue fortesting or processing, you'll need a 
system to manage the status of this submission 
and any failure in the submission step. The 
system should send accurate and informative 
feedback to the artist or developer— via email or 
lodged bug— as to why the asset failed the 
submission, and update the asset's status in the 
task tracker system. The artist will know what 
needs to be fixed and will be aware that the 
submitted asset is problematic, without having 
to wait for someone to scream at them for 
submitting a busted asset into the pipeline. 

Asset validity. There should also be a system 
created to provide instant feedback on the 
validity of an asset. This sanity check acts like a 
firewall to block assets that are invalid before 
they get into the art pipeline and tie up 
resources. This system is also very helpful for 
the artists to understand why their asset is 
invalid from a technical standpoint by providing 
instant feedback. The more detailed feedback the 
system provides, the more helpful it will be to 
educatingthe artists about the technical 
constraints of the game. 

The sanity check system should never 
automatically make changes to an asset without 
the artist's specific authorization. The system 
should behave like an impassive adjudicator of 
the assets, reporting problems to anothertool 
that can attempt to make a repair, if authorized. 
Any system that automatically makes changes 
to an asset will confuse and frustrate artists 
because they don't know why the changes are 
being made. 

FLOW OF COMMUNICATION 

Connecting artists. There should be a system 
and structure that allows artists to communicate 
with each other easily, such as the Visor tool in 
Maya or Alienbrain. This system should include 
an infrastructure to share assets, resources, 
techniques, and references. Typically, a library 
system, a really big database with a set of tools 
to navigate and filter entries, works best. 
Facilitating communication among artists is a 
critical component when creating a pipeline for 
larger art teams. 



Departmental communication. Notification 
systems to tell other departments that an asset 
is ready and the ability to get untested assets 
from the art department are mandatory features 
of a good art pipeline. Sometimes, departments 
such as sound and design don't need the final 
gold stamped asset from the art department but 
are happy with somethingjust recently exported 
from an artist. Also, a department will often 
request the most recent version of an asset, but 
cannot wait the hours or days it will take for it to 
filter through to the latest build. This component 
also links into the "feedback/critique" and the 
"asset tracking" components of the pipeline. 

Connecting companies ( outsourced]. If you 
plan to utilize external studios or freelancers 
during development, you need to shape the 
pipeline to support the tracking and flow of 
assets to and from those studios. Keep your 
outsourced studios in mind too when designing 
any proprietary tools and systems. Typically, if 
you treat each artist in your development team 
as though they are external (thereby treating the 
local network like an external network), when 
you come to synchronizing tools with artists 
outside of your studio, you will already have the 
infrastructure to support it. 

Facilitating feedback and critiques. Finally, all 
pipelines need to incorporate a system to 
manage the feedback and bug-tracking of an 
asset. You should keep track of exactly why 
assets failed certain steps in the pipeline and 
required reworking. If you plan to outsource any 
part of development, then the feedback and 
critiquing system needs to be able to provide 
limited access to users outside the studio. It also 
needs methods through which the external 
studio can request more detailed information on 
why the asset failed, or more general 
development questions about the asset. 
Typically, this component of the pipeline is 
managed by a bug- or task-tracker, which is a 
good fit. 

THE POLISHED PIPE 

The best thing any technical art director of a 
next-generation title— and for anyone working 
with the assets that the art team provides— can 
do for his or her art team is implement a well 
thought out pipeline. The goal of any pipeline is 
to enable and facilitate, not hinder, art 
production. Artists will appreciate all the 
measures put into the pipeline's design that help 
them communicate with one another, track the 
progress and stability of assets, and update their 
tools as necessary. 

The more structured and smooth the pipeline, 
the quicker and more efficiently your art team 
will work and iterate, increasing the level of 
quality of the work the team produces. :•: 
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TORU IWATANI'S 
RHAPSODY IN YELLOW 

I THE ORIGINAL CONCEPT FOR PAC-MAN WAS THE RESULT OF 

my desire to create a game that everyone could enjoy. With a 
female target audience in mind, I wanted to create a game 
based on eating (which is why the name comes from the 
Japanese onomatopoeic word pakupaku, the sound one 
makes when opening and closing one's mouth while eating). 
When I was thinking about this, I was at a restaurant and 
noticed a pizza with a slice missing. I thought, "This is it!" 

This was the inspiration, and it became the shape and 
general concept for PAC-MAN. Around this time, game 
amusement centers were saturated with games where killing 
aliens was the main objective. Lots of these games had great 
concepts that were fun to play, but I felt that none of these 
were equally accessible to women. Games at the time lacked 
variety— these types of games had a rather brutal image and 
a largely male audience. I wanted to liven up the game 
amusement centers by bringing female gamers, as well as 
couples, to the scene. 

I was inspired by several of Atari's games in this regard; 
they had some innovative concepts which taught me a lot 
about design. I had no doubt that the concept for PAC-MAN 
would appeal to women, even though I didn't spend a lot of 
time seeking their opinion on the ideas. After all, even in the 
fashion and jewelry design industry, you have male designers 
creating items for women. I was confident that my creation 
was somethingthat women would find appealing, so I just 
used my own intuition. 

When drafting the original proposal for the game, I kept 
PAC-MAN to myself. When I finally showed the proposal to 
my boss and colleagues, the response I got wasn't all that 
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overwhelming. I had already created three other games prior to 
PAC-MAN, so I was already known to be a game designer among 
my colleagues. As a result, most people were able to look 
beyond this different kind of concept and let me explore the 
game's possibilities. 

WHAT WENT RIGHT 

1 LOW-PRESSURE ENVIRONMENT. When we were making 
I PAC-MAN 25 years ago, we didn't have the same budget 
constraints or deadlines that most developers encounter today. 
Without this kind of external pressure, we were able to create 
something we were all very satisfied with in an environment 
that supported creation. Even so, we weren't able to include 
absolutely everything we wanted, even in 1980! 

2 SMALL TEAM VALUES. Unlike the large-scale projects most 
developers work on today, our team consisted of a mere 
five members, so it was easy to control workflow. 

Communication problems and team 
chemistry were not an issue, since we 
were all so close. In order to effectively 
manage a large project, everyone on 
the team needs to think somewhat 
along the same lines— to work toward a 
common goal. If you leave out the 
communication aspect, yourteam will 
fall apart. The process of making games 
today is much more complicated than it 
was in the PAC-MAN days, so we were 
able to thrive with a very lean 
development team. 
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SIMPLE DESIGN. We succeeded in 
makingthe game simple. When we 
were trying to bring out the exciting and 
fun elements in the game, we mostly 
used a trial-and-error approach. When 
working on the design though, we had to 
remind ourselves not to sacrifice the 
game's simplicity, since it was the one basic idea we had agreed 
upon when we began work. We wanted to make a game that 
would appeal to all levels of players and all genders, and included 
settings that would adjust the overall difficulty over time, such as 
attack waves and run delay zones for the ghosts. We put a great 
deal of effort into including these settings so it would be 
challenging for a wide range of players. It took a significant 
amount of time for us to playtest and to fine tune the various 
factors to reach the right level of balance. 

WHAT WENT WRONG 

1HARD SELL. Since so many of the popular games at the 
time were similar, we had some trouble explaining the 
basic game concept to both our colleagues at Namco and the 
general public. It was especially difficult for us to explain the 
concept of how PAC-MAN, who spends most of his time avoiding 
ghosts, is able to turn the tables and chase the ghosts after 
eating a power cookie. Internally, we received a lot of 
suggestions on how we could improve the game and make it 



easier for players to understand. For 
example, the president of the 
company requested that we change 
the color of all the ghosts to red, even 
though they all had independent Al 
routines and personalities. 
Fortunately, the game explained 
itself when people saw or played it, 
so our concerns about confusing 
players were largely unfounded. 



2 




ARTIFICIAL INTELLIGENCE. The 

one area of the game I would 
have liked to refine more if given the 
time is its artificial intelligence. I am 
pleased with the Al that exists in the 
game, but I would have liked to 
implement a system where the 
difficulty of the Al is automatically 
controlled. I anticipated that having a 
set difficulty curve would not be 
enough to cover the entire range of 
people that would play it. We wanted 
to have a system in which the 
computer could tell whether a 
beginner or an expert player is at the 

controls, based on the time it took the player to make a mistake. 
A record of these mistakes could be kept on the system, so it 
could automatically adjust the level of the Al in real time. We just 
didn't have enough time in our 15 month production schedule to 
implement that system. We also considered a few additional 
game features, such as gates that would trap the ghosts, but 
these also had to be sacrificed in order for us to finish on time. 

3 TECHNICAL DIFFICULTIES. For the most part, we didn't run 
into too many technical problems during development. The 
developers on ourteam were all quite good, and as mentioned, 
we chose to keep the game simple in order to avoid potential 
technological issues. I think ultimately, we were able to create a 
simple game solely because there were techniques we didn't 
know about, through which we actually could have realized a 
more complex design. In that sense, it was better that we didn't 
know about them! The one technical problem we did encounter 
was with the animation. We ran into a few issues animating the 
non-game scenes, but managed to still create something 
compelling with a lot of personality. 
We had always wanted to create an 
animation style that people could 
chuckle at, since we wanted it to 
appeal to multiple audiences. We 
knew that in order for the game to 
become a successful franchise, we 
needed a main characterthat was 
positive and upbeat, and would make 
players smile while they played. The 
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Pac-Man creator Toru Iwatani and friends. 



same goes for the ghosts— the game needed an enemy, but we 
wanted something with a cute design. Fortunately, we were able 
to work around this one technical constraint with some 
excellent programmers to make PAC-MAN come alive. 

EDITOR POSTMORTEM: 



PAC TO THE FUTURE 

I'm delighted that PAC-MAN has gained such 
popularity worldwide. We knew we had a high 
quality product after we finished the game when 
we realized there was nothing that could possibly 
be added or removed to make it better, aside from 
the minor issues I mentioned. Even still, we were 
uncertain as to how successful the game would 
be overall. We had no idea that it would become 
such a big hit around the world. Even after its 
success in Japan, we didn't anticipate the 
overwhelming reaction from overseas. Even 
young players today know PAC-MAN due to its 
consistent presence on consoles generation after 
generation, but most of all, I have the simple 
game design and adorable characteristics of PAC- 
MAN himself to thank for this success. 

As the developer of PAC-MAN, I was able to get to 
know a lot of people that I otherwise would not 
have had the opportunity to meet. These people 
are all very important to me and I feel fortunate to 
have worked on such a special game. All of us who 
worked on PAC-MAN learned some important 
lessons that can apply to any game developer. 
First, it is important to make a game that your 
target player will enjoy, and not just a game that 
you would like to play. In that respect, it's 
important to have a service-oriented mindset. Additionally, 
developers should believe in themselves and strive for their 
goals, knowing that they can succeed at anything with bravery, 
energy, and a sense of mission. 




Pac-Mania brought the Pac-Man 
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THOUGH TORU IWATANI'S IMPRESSIONS OF HIS WORK CREATING 

the original Pac-Man game are vital and fascinating, they 
obviously don't tell the whole story. Twenty-five years and 
countless titles later, Namco continues to grow and expand the 
PAC-MAN franchise. But clearly, just as there were ups and downs 
in creating the original arcade game, there have been similar 
pluses and minuses in the creation and nurturing of PAC-MAN's 
legacy. Game Developer decided to take a close look at a quarter 
century of PAC-MAN games and come up with its own objective 
list of What Went Right and What Went Wrong in terms of the little 
yellow guy's growth. These, then, are our independent 
impressions of how the franchise has fared, and what Namco 
still has to work on before PAC-MAN inevitably takes over the 
world some time later this century. 

WHAT WENT RIGHT 

<1 PAC-MAN: THE FIRST GAMING ICON? PAC-MAN, many would 
I argue, was the first ever gaming icon— a recognizable video 



game character that was embraced by millions, even 
transcending video game media in his appeal. Why such a 
breakthrough? Well, prior to Pac's genesis, early video games 
often didn't even have characters at all— rather, the protagonists 
were spaceships or paddles. Even those that did include 
characters were largely disparate from the illustrations and 
designs upon which they were based. 

But PAC-MAN's simple, cute, yet compelling character design 
allowed him to be easily identified, both in pixilated digital and 
stylized drawn form. As a result of the smash success of the 
first PAC-MAN game, Pac's likeness made its way to everything 
from lunchboxes to Saturday morning animated series, and 
pervaded early '80s culture far more than anyone could 
reasonably have expected. The crowning example of this is 
probably Buckner 8c Garcia's number eight hit in the U.S. charts, 
"Pac-Man Fever"— novelty songs are one of the best signs that 
you have a genuine phenomenon on your hands. 

But since then, cultural awareness of PAC-MAN hasn't really let 
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up, showing that recognition of and love for the little yellow puck 
isn't just a fad. Aphex Twin, Weird Al Yankovic, and Argentinean 
concept rock group Patricio Rey y Sus Redonditos de Ricota have 
also recorded PAC-MAN-related musical numbers. And as recently 
as this year, Namco reached a settlement with hiphop star LIT Flip 
over his sampling of PAC-MAN sound effects for his hit "Game 
Over." Also in the recent past, PAC-MAN music and gameplay 
themes were used for a subtle North American Volkswagen 
commercial in which the car picked up pellets and fruit, ending on 
PAC-MAN's classic game over sound. The fact that the game itself 
was not specifically mentioned, but Volkswagen still felt confident 
in riffing off the sounds and themes surrounding PAC-MAN shows 
the true profile of the franchise within contemporary culture. 

2 SEQUEL-BUILDING BY ITERATION. For a time, the PAC-MAN 
series evolved not in over-ambitious leaps, but in baby steps, 
refining the already proven model of the original, whose chase- 
and-be-chased 2D gameplay was a major innovation that spawned 
any number of clone titles by rival arcade game creators. Namco's 
careful nurturing of the series is evident in the love many players 
still have for some of the earlier PAC-MAN sequels. This is 
particularly true for MS. PAC-MAN, the first, and most successful 
iteration of this type, and still one of the most beloved titles. 

In fact, the game was not made by Namco at all, but by the 
small American firm General Computer Corporation as an add-on 
to the original PAC-MAN arcade board. But it's to Namco's (and 
U.S. licensee Midway's) credit that they appreciated the 
improved gameplay and even more female-friendly nature of 
the pseudo-sequel and brought it within the fold as an official 
part of the PAC-MAN franchise. This iteration-like sequel model 
worked well for a time, and there were some fun twists which 
still preserved the addictive original gameplay, including the 
1987 isometric PAC-MANIA and the enjoyable extension MS. PAC- 
MAN MAZE MADNESS (2000), each with its own charms achieved 
through working off the original's innovations. 

3 INTELLIGENT EXPANSION OF GAMEPLAY. While PAC-MAN has 
sometimes had trouble expanding past its 2D maze-based 
roots, some franchise extensions have worked particularly well, 
especially when they consider carefully what the essential nature 



of PAC-MAN's appeal is and base the gameplay on those points. In 
particular, Namco's recent collaboration with Nintendo's Shigeru 
Miyamoto and excursions onto the Nintendo DS system have been 
fruitful in terms of serving up fresh ideas for our little yellow friend. 

Specifically, Miyamoto's experiments for PAC-MAN VERSUS, 
which pits a PAC-MAN-controlling player on the GameCube 
against players controlling ghosts on multiple Game Boy 
Advances, doesn't change the nature of the game's design 
much on paper. But what it does change is the way people play 
and interact with the game, which makes it feel fresh and fun. 
On a similar note, PAC-PlX for the Nintendo DS starts with a 
charming set up— the ability to draw your own PAC-MAN with the 
DS's stylus and then control which way it moves onscreen to 
gobble up the ghosts, a perfect idea for a franchise evolution. In 
similar form, PAC'N ROLL for the DS is another smart extension— 
the innovation of control by rolling PAC-MAN with a stylus is the 
most compelling part of the experience and helps remind us of 
the viscerally direct control of the arcade original. 

WHAT WENT WRONG 

1 A DIFFICULT TRANSITION TO 3D. PAC-MAN's transition into 
I the 3D world, and in particular the world of 3D gameplay, 
has not been an easy one. While it has been established that 
departing from the original PAC-MAN design can yield good 
results, the PAC-MAN WORLD games, while enjoyable on a basic 
level and relatively commercially successful, ultimately place 
PAC-MAN in a 3D platforming space alongside the likes of MARIO 
64, Ratchet & Clank, and Crash Bandicoot. 

This, needless to say, is a difficult area to compete in, and 
since PAC-MAN traditionally operates in a restrictive 2D maze 
medium (as opposed to, say, Mario, whose 3D adventures 
would be much easier to envision even if MARIO 64 did not exist), 
it's not as simple to place him in a freeform three-dimensional 
world, and so his 3D excursions, like those of other early arcade 
icons, feel a tad limited. As a result, the 3D PAC-MAN games have 
lacked much of the critical adoration given to competing titles 
and don't tend to register high on the list of must-play games for 
hardcore gamers, although their gameplay ends up working out 
well for the casual mainstream market. 

2 LACK OF DIRECT CREATOR INVOLVEMENT. PAC-MAN's much- 
loved creator Toru Iwatani was indisputably the visionary 
behind the first PAC-MAN title, and continues to work at Namco 25 
years later. He was at the helm of Namco's games division all those 
years ago, designing the company's first-ever arcade title GEE BEE 
and two sequels, before making PAC-MAN. After the completion of 
one furthertitle, LlBBLE RABBLE, he stepped out of the development 
sphere and into Namco's administration. 

Though Iwatani continues to contribute to the company's overall 
direction and creative think-tank, he has not directly designed a 
PAC-MAN game since the original. When asked at Game Developers 
Conference 2004 what one element he would add to the original 
game, he said, essentially, that he would add nothing. The game 
was so simple that adding anything extra to it would be too much, 
and taking anything away would breakthe gameplay. 

This may help explain both why Iwatani has not worked 
directly on the series since its inception, and why it has 
sometimes been difficult to transition the game into the next 
generation. Although Namco has done a fine job of continuing 
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IF YOU'RE IN THE VIDEO GAME INDUSTRY, DEALING WITH JAPAN 

is right up there on the list of inevitabilities with death and taxes. 
Many industry veterans, whether in development, business, or as 
employees of Japanese companies, come away from their first 
exposure dazed and confused. This does not have to happen. Let 
me share a few myths and offer some related advice. 

MYTH AND METHOD 

Myth: The Japanese are one people, and Japan is special and 
different 

These notions got rolling during the Meiji period (1868-1912), 
when the Japanese government made pounding them into the 
nation's head a priority. Japan is a diverse country full of different groups, cliques, 
and values. The who, where, and why of those differences are far more important 
to understanding a situation than the mere fact of Japanese-ness. As for Japan 
being special and different, yes, it is— so is every nation. That doesn't make it 
unique in any larger sense. Common sense goes as far in Japan as anywhere else. same page as your partners. 




verbal. My advice: Create a contract where every line is meaningful, review 
the contract carefully with the other party, and when everyone feels 
comfortable, sign. No paper will protect you from everything, but a 
meaningful and well reviewed contract is your best shot at staying on the 



Myth: Yes means maybe, maybe means no, no means never. 

This comes from a mixture of bad translation and consensus-based decision 
making. Japanese is not an ounce less direct than English. For example, "I'll 
think about it" ("kangaeteokimasu") is simply a polite idiom which actually 
means "no." The term, used in context, is not subtle or ambiguous but could 
throw you for a loop if translated literally. If you use a translator, use a good 
one. And if you are not sure what someone is saying or sense they aren't 
following you, ask questions to confirm understanding. 

The consensus-based decision aspect is a little more complex. One fairly 
consistent feature of Japanese businesses, especially older ones, is a 
disbursement of responsibility. The person you are talking to may want to say 
yes, but does not alone have the authority to commit the organization and 
may be embarrassed by this, or may assume you understand his position. 
The solution is, if someone promises they'll do something, confirm key points, 
who, what, and when. It's not rude, and it will prevent much heart-ache later. 

Myth: Japanese business works without lawyers. 

To quote Mark Twain: Lies, damn lies and statistics. Yes, there are very few 
attorneys in Japan, and a bar pass rate of about three percent keeps it that 
way, at least for now. However, most companies have a legal section filled 
with non-attorneys, many with undergraduate law degrees, who take on 
exactly the role filled by lawyers in the U.S. or Europe. For all practical 
purposes, you'll be dealing with lawyers. Just rememberthat actual 
knowledge of the law in these legal departments varies widely. 

Myth: Contracts don't matter in Japan. Its all about oral promises. 

Again, it depends on the person and relationship. There are certainly people 
who, when handed 20 pages in a language they don't read and asked to sign, 
"for form," will. There are others who don't keep their promises, written or 



Myths: Business is done in English in Japan. Doing business in Japan in 
English is a problem. 

Yes and no to both. English conversation is certainly a specialized skill in 
Japan, a country which in 2000 was proud to finally do betterthan 
Afghanistan, Cambodia, and Laos, and finish 18th out of 21 Asian countries in 
the Test of English as a Foreign Language. But it's hard to go through junior 
high, high school, and college without at least six years of English instruction. 
The disconnect probably comes from a system that teaches English to be 
passively read, maybe written, but rarely spoken or heard. 

I suggest that if you need to communicate but don't share a spoken 
language, try writing— just be sure to write clearly and concisely. 

Myth: A production pathway is a production pathway, and a milestone is a milestone. 

Both the U.S. and Europe have large export software industries producing 
applications in just about every field. Japan's only major software export is video 
games. The relative lack of a surrounding software industry has allowed 
Japanese game production to develop somewhat distinct practices. For example, 
even now, basic design often happens during production (put something on the 
screen, then figure it out), milestone definitions differ (Japanese beta is typically 
U.S. alpha) and schedules are loose, even by our industry's standards. 

My advice: Work with the reality. You want your project to use U.S. 
milestones? Want lots of pre-production design? Define the milestones 
carefully, educate and lead the team, and most will be happy to oblige. Got a 
good team you really trust to work without supervision? That's fine, but 
understand from the start the level of documentation you will get. Most 
importantly, get good people and teams with strong track records. No 
amount of communication or awareness will get good work from a weak 
team, but a strongteam will usually find a way to work underthe most 
challenging circumstances. 
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Dealing with Japan, whether it's a brief brush or a lifetime affair, does not have 
to be the Alice-in-Wonderland experience many in the industry report. Just do 
your job well, use the common sense and the good practices you would 
anywhere else, stay flexible, and enjoy the ride. :•: 
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PRACTICAL HASH IDS 

Using a 32-bit CRC hash as a unique identifier for game resources 




GAME ASSETS FREQUENTLY NEED TO BE 

referenced indirectly by the engine, by 
code, and by scripts. The simplest way to 
do this is to use the name of the object. 
However, this method is very inefficient 
and otherwise problematic. 

Let's re-examine the practice of using a 
32-bit hash of the name as a unique ID 
and explore some ways of integrating 
this into your code and tool pipeline. 

PREMATURE OPTIMIZATION? 

This article is about an optimization. 
Optimizations are typically done at the 
end of a project. The Art of Computer 
Programming author Donald Knuth 
famously quotes British knight and 
computer scientist Tony Hoare saying, 
"premature optimization is the root of all 
evil," but prefaces this with an important 
caveat, "about 97 percent of the time." 

The 32-bit hash optimization is a case 
that belongs among that three percent 
(or more, opinions vary) best done early. 
It's such a fundamental change that it 
affects many aspects of the game engine 
code and data structures. It's not an 
optimization you do at the end to speed 
things up, but rather one you do at the 
start because it enables you to do more 
right from the early stages of development. 

THE NEED FOR ASSET IDS 

A game contains a very large number of 
assets, including meshes, textures, 
animations, skeletons, scripts, sounds, 
effects, triggers, events, NPCs, and 
various other miscellaneous resources, 
objects, and entities. 

These assets all need some way of 
being referenced, either as part of some 
internal linkage (a mesh will reference 
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the textures it needs) or as some 
intentional reference on the part of the 
designer ("play the Manjump Ola 
animation" or "blow up building 
City 04 BankOl," for example). 

These references need to be resolved 
at run time, as this gives you a much 
more dynamic development environment 
than statically linking everything 
together at compile time. Assets can be 
changed independently and re-loaded. 
Small sections of the game data can be 
recompiled quickly without having to 
recompile everything. (See Sean Barrett's 
"Late Binding Data," February 2005.) 

The assets will nearly always have a 
name. Textures have the file name of the 
original .PSD, .PNG, or JIFF Scenes 
exported from 3D Studio Max or a similar 
package will have a name associated 
with each object in the scene. 

So the simplest way to reference an 
asset is to just use the string containing 
the name. This has a great advantage in 
that it's very straightforward. But, there 
are several disadvantages, too. 

PROBLEMS WITH STRINGS 

First, using the string that contains the 
name takes up a surprising amount of 
memory. Asset names are often quite 
long, especially if paths are included. If 
every mesh has to reference every 
texture it uses by name, then that can 
add up to an unnecessarily large amount 
of memory. 

Second, comparing two strings takes a 
lot longer than comparingtwo numbers, 
so this solution is slow. Quite often asset 
names will have long common prefixes, 
meaning you get a lot of false partial 
positives if you are looking up the string in 
a table. Plus the length of the string means 
you need to perform a large number of 
memory accesses, which can be very slow 
on architectures with expensive data 
reads, such as the PlayStation 2. 

Third, it does not fit into data structures 
nicely. The strings are of random length, 
making it difficult to form neat data 



structure around them. 

And finally, having a large number of 
strings visible in the data might be 
something of a security concern. Plot 
spoilers might be deduced from the 
names of assets ("Hey, what's this 
'MDL SPIDERWOMAN'? Sweet!"). And if 
you want to stop people from hacking 
left-over content in your game (like the 
infamous Hot Coffee mod in Grand Theft 
Auto: San Andreas), then you're better off 
not giving them a load of clues. 

USE THE HASH VALUE 

Instead of using the string itself, one 
approach is to use a hash value of the 
string. A hash value is a number 
calculated by mangling the bits of the 
string together using some algorithm to 
produce a fixed number of bits. There are 
various hash algorithms that produce 
various sized outputs. Algorithms such 
as SHA, MD5, or RIPEMD-160 produce 
hash values of 128 or 160 bits in length 
(16-20 bytes) and so don't really help us 
very much. 

The string hash algorithm that best fits 
our needs here is CRC-32, which takes a 
string and gives you a 32-bit value. The 
algorithm is specifically designed so that 
small differences in a string produce 
very large differences in the output. This 
is very important, since you don't want 
string such as "ANIM 10002" and 
"ANIM 20001" to result in the same hash 
value (as they would if you did a 
traditional checksum where you added or 
XORedthe bytes or words together). 

Using the hash in place of the string 
immediately removes the problems that 
I've already mentioned. Comparisons 
are now very fast, since you only need 
to compare two 32-bit values. Memory 
accesses are reduced to a bare 
minimum. Data structures can now have 
a nice, neat, single 32-bit word to store 
the reference rather than a variable 
length, memory-hogging string. 

Using a hash has other benefits. Since 
it's a hash value, you can use it as a very 
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.ISTING 1 



// crc_hashes.h 




#ifndef __CRC_HASHES_H__ 




#define __CRC_HASHES_H__ 




#define CRC_MDL_MECH01_LARGE 


0x4854987A 


#define CRC_MDL_MECH02_LARGE 


0x374FAAD2 


#define CRC_ANM_FOX_JUMP 


0xF003C8A8 


// add additional crcs here . . 




#endif 





A header file containing all the hash values. 



fast index into a 
hash table simply 
by lopping off 
however many bits 
you need— for an 
8K table, just use 
the bottom 12 bits. 
Or even easier, you 
can pick 12 bits out 
of the middle of the 
word to match the 
power of 2 
alignment that your 
table is on (so, if 
your hash table 
index is 8 bytes per entry, then just mask 
off bits 14 through 3, and you've got the 
offset into your hash table index). 

Another useful technique applies when 
game assets need to have pointers to 
each other. By using a 32-bit hash you 
can write out a data structure identical to 
that used in the game, but with the hash 
values in the memory location usually 
occupied by the pointers. Then when the 
asset needs to be loaded and bound into 
the game, you simply replace the hashes 
with the appropriate pointers. This 
removes the need for building data 
structures from parsed data, and can 
greatly speed up the loading process, 
while still giving you the flexibility of late- 
binding data. 



FEAR OF COLLISIONS 

So why don't people use hashes for IDs? 
Well the first thing people think when 



LISTING 2 



inline uint32 check_hash(uint32 id, const char *name) 
{ 

assert (id = crc32(name)); 
return id; 

} 




#ifdef DEBUG 

#define HASHCHECK(id, name) check_hash(id, name) 
#else 

#define HASHCHECK (id, name) id 
#endif 



A macro for checking your hashes at run time in debug mode. 



presented with this idea is "what if 
there's a collision?" 

A collision is when two strings have the 
same hash value. Since with a 32-bit 
hash value there are only about 4 billion 
possible hashes, if you throw enough 
strings in, you will eventually find two 
that have the same hash value. 

The probability that any two strings will 
have the same hash value is 
1:4,294,967,296 (about 1 in 4 billion). 
With a larger number of strings, the 
probability rises. At about 65,000 strings 
there is an approximately even chance 
that there will be a collision— at least one 
pair of distinct strings will have the same 
CRC-32 hash value. 

For a practical example, I did a check for 
collisions on 89,000 unique strings 
culled from some random dump of a 
dictionary, and there was only one 
collision. The strings "bellys" and 
"cochleariform" both have the same 
CRC32 (0x5DlF90F6). Laterwhen 
checking a list of 216,000 strings, I only 
got seven collisions. 

Remember there is a big difference 
between finding a collision somewhere in 
a large set of strings, and the possibility 
of a new string causing a collision. If 
you've already got 89,000 strings with 
no collisions, and you add one more, the 
chances that there will now be a collision 
are 89001/2 32 or about 1 in 50,000. 

So depending on how many IDs you 
actually use, you are going to have to 
deal with collisions very rarely. 

DETECTING AND 
HANDLING COLLISIONS 

But collisions will occur, and at some 
point you will need to detect collisions, 
and then deal with them. 

To detect collisions, you need to keep 
an automated central database of all 
the strings and hashes that are used. 
This database is solely used during 
development, so it doesn't require any 
overhead in the actual game. It need 
not be complex. Just a simple list will 
usually suffice, and you don't need to 
worry about removing unused entries- 
just purge it whenever you do a full 
rebuild. 

When you find a collision, the simplest 
way to deal with it is to change the string. 
Now I know that this sounds like a rather 



hacked-in solution, but it's really not 
going to happen very often. You'll 
perhaps have to change a string once a 
month towards the end of the project, and 
not at all during the first half of the 
project, when the number of unique 
strings is still very low. 

USING HASHES IN CODE 

The other reason that people don't use 
hashes is that they can't read them. A 
simple implementation of this system 
would involve someone running a CRC-32 
program on the string, and then manually 
typing in the checksum into the code 
where the asset was being referenced. 
Instead of typing 

"LoadAsset("MDL_ENEMY_GUNSHIP")" , 
you type LoadAsset(0x23C55C3A). Nasty. 

Ideally the user (in this case the 
programmer or designer) should never 
have to see these hexadecimal strings. 
The entire process should be automated 
to make it both easier to read and less 
prone to errors. (I've cut and pasted the 
wrong hash value a few times in the past.) 

When dealing with compiled data such 
as meshes, animations, textures, and so 
on, this is relatively straightforward. You 
just compile the strings into hashes 
when you compile the data into whatever 
engine specific format you need. 

When you need to reference an asset 
from C/C++ code, the story is somewhat 
different. Here are fourways of doingthis, 
in the order I first considered using them. 

1. Just use the hash values directly. 
Not a very good option. You'll type them 
in wrong, and there's no easy way of 
figuring out if it's the right hash value. 
You can improve things slightly by 
adding a comment next to the hash 
value, but it's still a messy and fragile 
method. 

2. Use ttdefines. In this system, you 
add all your strings to a header file (say 
crc hashes.h), with a line for each 
possible string (see Listing 1). Then in 
the code you just use the CRC symbols. 
This initially seems like a reasonable 
option, but suffers from the huge 
downside that you have to include 

crc hashes.h in every single file that 
uses a hash value. This effectively 
means that whenever you add a new 
hash, you need to re-compile a 
significant portion of the game. 
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A description of the CRC-32 algorithm 
http://en.wikipedia.org/wiki/CRC32 

A practical and public domain implementations of CRC32 
http://www.csbruce.eom/~csbruce/software/crc32.c 



3. Use a macro that checks the hash 
value, but is compiled out in "ship" mode. 
(See Listing 2, pag e 34. ] With this you 
enter in both the string and the hash 
value directly into the code (see the 
example in Listing 3). 

This ensures your hash values match 
your strings. In ship mode it will compile 
away to leave just the hash value itself. 
This works well enough, and it's relatively 
straightforward to set up a hot key your 
editor to automatically generate the 
hash, and the call to HASH(), and insert 
them in the code, so you don't ever have 
to deal with the hash value directly. 

However there are still problems. First, 
you've still got the hash value there in the 
code, leaving you open to cut-and-paste 
problems. Second, the check is at run- 
time, so if it's an obscure bit of code 
(maybe it only runs at the end of the 
game), then the check might not fire until 
a few weeks after you add it. Third, it's 
slow in debug mode since you have to 
generate a checksum for each string. 

As I wrote in another article ("Debug 
and Release," October 2005), I don't think 
there should be separate debug and 
release modes, but rather a single 
"develop" mode, used for both purposes. 
Having the code check the value of a 
hash value against a string is slow, and 
it's done too many times. The hash value 
might be used several times per frame, 
but if it's right once it's always going to 
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// 


hash value directly: 






Load(0x334BDCF8); 




// 


hash value with inline comment 






Load(0x334BDCF8 / *MDL_MECH01_L ARGE*/) ; 




// 


using #define in a common header file 






#include crc.hashes.h 






Load (CRC_MDL_MECH_01_LARGE) ; 




// 


Using a macro to check vlues 






Load (HASHCHECK (0x334BDCF8 , "MDL_MECH01_LARGE")) ; 


„ 


Using additional preprocessing 






Load (HASH ("MDL.MECHOl.LARGE) ) ; 




// 


The same line after the custom build step: 






Load(0x334BDCF8 / *MDL_MECH01_LARGE*/) ; 











be right. You can hack the macro so it 
only checks once, but you've either got to 
add another check, or write some self- 
modifying code. 

4. Use a custom preprocessor. With this 
approach everything is automated for 
you, you simply use the string itself and 
tag it by placing it as a parameter, a 
pseudo-function, called HASH (). You then 
need to introduce a custom build step to 
your build process that scans your source 
for calls to HASH(), and replaces them 
with the correct hash value. (See Listing 
3 for a comparison of all these methods.) 

The great benefit of this system is that 
the programmer never has to see (or 
type) another hex string in order to 
reference something in the game. Once 
the system is set up, the programmer 
can continue to refer to assets by name, 
and the optimization of using hash 
values will take place under the hood. The 
disadvantage is that you have to add a 
custom build step that generates 
intermediate files to be compiled. If you 
already have such a step it's probably not 
such a big deal to extend it to include 
this. But changing your build process is 
not a trivial task. 

Introducing a custom build step runs the 
risk of making your code less portable. A 
new platform might not be as flexible in its 
compiler options. To get around this, you 
can define the function 
HASH() as a function that 
calculates and returns the 
checksum of the string 
passed to it. That way, even if 
the additional compilation 
step is missing, the code will 
still work perfectly (albeit a 
little slower). 

One additional place in 
your code where the use of 
these string id hashes needs 
special consideration is in 
switch statements. Since the 
value after a case keyword 
must be an absolute value, 
and not the return value of a 
function, then using the 
HASHCHECK() method will 
not work. A custom 
preprocessing step will work 



fine, as the value is automatically inserted 
and there is no use of macros. However 
now the fallback method of also defining 
the HASH() function will not work for 
switch statements. 

OTHER CONSIDERATIONS 

By default, CRC-32 is case sensitive. For 
this use though, it is probably a good 
idea to make it case insensitive. This is 
especially true if you are going to use 
hashes in some kind of script 
environment used by designers. Since 
you never really want to have 
MDL BigJumpOl mean something 
different from MDL BigjumpOl, then it 
makes everyone's life easier. Making 
your CRC routine case insensitive will 
also not make it any slower if you use a 
table-based method (just duplicate the 
upper case entries with the lower case 
entries). 

If you are using hashes to uniquely 
identify objects in the game, you might 
want to reserve some for specific 
system objects. You could do this by 
adding a few names like SYSTEM 0001, 
SYSTEM 0002, etc. Or you can simply 
reserve the first, say 1,024 values. 
(0x00000000 through 0x000003FF), 
and explicitly report them as illegal 
values in your database. This might 
seem a little odd, not allowing this range 
of values for a hash, but only one out 
over every 4,194,304 possible strings 
will have a hash value in this range. 

Given a hash value from a string A 
(HASH(A)), and given another string B, 
then you can calculate HASH(A+B) by 
calculating HASH(B) using a starting 
value of HASH(A). This means you can 
calculate HASH(A+B) without ever 
knowingthe actual contents of the string 
A. This is very useful if you have assets 
that have a series of different extensions 
or other appended strings (for example, 
MDL_R0B0T_01_ might have 

mdl~robot~oi~left_arm, 

MDL~R0B0T~01~LEFTJ_EG, etc.). Then you 
can quickly calculate the hash values of 
the string with the extensions without 
having to know the original string. :•: 



Showing the different ways of using hash values in code. 
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ANIMATORS PART I, Spinal Tips 



LAST MONTH WE REVIEWED SOME 

anatomy for animators, concentrating on 
the legs and feet. This month, we'll 
continue with a look at the anatomy of 
the spinal column, includingthe body, 
torso, and neck. 

The spine, naturally enough, forms the 
backbone of any good animation rig. 
Unfortunately, setting up a character's 
spine is daunting for a number of reasons, 
both anatomical and technical. It's obvious 
just from looking at a skeleton that the 
spinal column is a pretty complex 
mechanism, with 33 vertebrae and a 
complex re-curved S-shape. Luckily for us, 
most of this complexity can be abstracted 
into a much simpler set of animation 
bones. However, it's helpful to have a quick 
overview of the full system before moving 
on to a more animation-friendly one. 

Veterans of figure drawing know that 
the spine isn't straight. The basic shape is 
formed by a sweeping S-curve. The curve 
isn't just there to make for better looking 
charcoal sketches; the arch of the back 
works to increase the ability of the spine 
to carry weight, just as arches support a 
bridge better than flat girders. You see 
this principle at work in the classic 
contrapposto stance, in which the hips 
and shoulders are canted in opposite 
directions for support with minimal effort. 
The same principle also explains the 
comical forward thrust of a weightlifter's 
belly in a full snatch (see Figure 1). A 
good animation spine has to reproduce 
smoothly flowing curves, so it's important 
to understand how those curves are 
integrated into the structure of the body. 



THE IMPRESSIVE 
VOCABULARY SECTION 

Anatomists divide the spine into four 
major areas, each of which forms a 
distinct curve (see Figure 2). 

1. Sacral. The sacral section is the 
foundation, located inside the mass of the 
pelvis. Technically it counts as five 
vertebrae, although they're fused together 
into a single jumbo bone. The sacral 
vertebrae are basically part of the pelvis and 
don't move independently; however you can 
see the extension of the lower curve of the 
spine in the upper plane of the buttocks. 
Technically, the base— the real base— of the 
spine is the coccyx, ortailbone, which 
doesn't do much in the body except add 
three vertebrae to the total count. 

2. Lumbar. The lumbar section is the 
connector between the hips and the ribcage. 
It contains five vertebrae and curves 
forward toward the navel. The lumbar 
section is where most of the bending and 
twisting in the spine really takes place; 
thanks to that, it's also the source of most 
back pain. The forward curvature of that 
Herman Miller Aeron chair you got cheap 
after the dot-com bubble burst is intended to 
support a natural lumbar arch. 



STEVE THEODORE started animating on a text-only 
mainframe renderer and then moved on to work on games 
such as Half-Life and Counter-Strike. He can be reached at 
stheodore@gdmag.com . 




FIGURE 1 The curvature of this weightlifter's back 
is critical to his ability to sustain heavy weights. 



3. Thoracic. The thoracic section is the 
foundation of the ribcage. It curves 
backward, opposite the arch of the 
lumbar. Although it contains 12 vertebrae, 
it's much less mobile than the lumbar 
section. However, it does actually flex as 
the body turns and reaches, so it's 
incorrect to represent the ribcage as a 
completely solid block, particularly for 
side-to-side stretches. 

4. Cervical. The cervical section is the 
neck, which includes seven vertebrae. Like 
the lumbar, it actually curves forward in the 
rest position. Unlike the rest of the spine, 
though, the vertebrae of the neck are much 
closer to the center of the neck mass, so it's 
harderto spot the rhythm of the curve in a 
static model. However, you can easily see 
the effects of the curve by observing the 
neck in action in Figure 3. 

HOW MUCH IS ENOUGH? 

Regrettably, all this fancy anatomical 
knowledge doesn't translate directly into 
a good working animation skeleton 
without some extra planning. When 
roughing out a character skeleton, you 
need to consider the tradeoffs between 
visual fidelity, ease of animation control, 
and in-game performance. Generally, 
more bones will provide better deformation, 
particularly if you want to really capture 
that flowing line of action properly. 

But a precisely correct, 33-bone spine 
can create a lot of headaches for the 
animator and a lot of work for the game 
engine. Every one of those bones is 
another opportunity for the animatorto 
accidentally insert a kink into what ought 
to be a flowing line of action. Thirty-three 
nested transform matrices represent a 
lot of math, even for a modern game 
engine. Therefore, it's unlikely you'll want 
to build a character with an exact bone- 
for-bone version of a real human spine. 

Exactly how many bones will be 
enough depends on both the model and 
the application. Naturally, a high- 
resolution hero character demands more 
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attention than an extra in the non- 
playable character crowd. A minimal 
spine ought to include at least one joint 
for each region of the spine: a sacral joint 
just above the pelvis, a lumbar joint 
behind the navel, a thoracic joint behind 
the sternum, and a cervical joint at the 
base of the neck. 

As you increase the bone count, you'll 
get smoother deformations and more 
realistically sinuous motions, though you 
shouldn't simply distribute the additional 
bones evenly alongthe character's trunk. 
This is a bad fit for the way the body really 
moves. Most of the flexion of the spine is 
concentrated in the lumbar area between 
the hips and the ribcage, so this area 
should get more joints. The thoracic region 
(roughly, the ribcage) is about twice as 
large as the lumbar area, but it should get 
fewer joints. The sacral area is enclosed by 
the mass of the pelvis, so there's no point 
in adding extra bones down there at all. 
The inadequacies of standard smooth- 
skinning mean you don't get much visual 
reward for having more bones than 
vertices. As a rule of thumb, you probably 
won't need more bones than you have 
edge loops in a model's torso. 

One minor issue to watch out for when 
building naturalistic spines is that many 
animation packages are unhappy with re- 
curved bone chains. After you've laid 
down the bones for your spine, 
remember to check the local axis 
arrangements before you add the arm or 
head bones. Be sure that the local axis 
systems in the spine are lined up so they 
all respond the same way to pitch or roll 
inputs. If you're going to use Euler angles 
for rotation, make sure that the twist of 
the spine corresponds to the first term of 
your Euler rotation angle so you get more 
reliable twists and can use the Euler 
numbers to drive expressions (for more 
details on dealing with twists, see "Twist 
and Shout," April 2004). 

SOMEWHERE 
BETWEEN U AND 33 

Deciding on the number of spinal bones 
is relatively simple. The tricky part of 
buildingan animation spine is 
determining how strictly you will follow 



the correct anatomical placement of the 
spinal column. Game animators typically 
ignore anatomical correctness and place 
the spine pretty close to the centerline of 
the body. We're also much more likely to 
arrange the spine straight up and down, 
rather than in a biologically proper curve. 
Film animators, on the other hand, are 
more likely to use the anatomically 
proper position and curvature. 

The difference evolved mostly out the 
fact that games have pretty crude 
deformation tools. Central spine 
placement is a good defense against the 
loss of volume when the character bends 
forward. In film characters, where 
muscle systems or procedurally driven 
influence objects are common, the 
danger of crunching is much less and 
the attraction of correct anatomy 
correspondingly greater. 

Nowadays, the distance between the 
two camps is starting to diminish as 
game characters get more complex. 
Models with higher vertex counts can 
produce something closerto the 
appearance of a real abdominal crunch, 
instead of the disturbing accordion folds 
that result from realistic spinal placement 
on low-poly models. Moreover, we now 
have the horsepower to spare for volume- 
preserving fix-up bones in the belly. As it 
becomes easier to avoid the abdomen 
problem, the upsides of proper spinal 
placement— better rhythm in the curve of 
the body, less counter-animation when 
twisting the torso, and more realistic 
separation of the ribcage and pelvic 
masses— become more attractive. 

If you're used to working with central 
spines, it may be time to start 
experimenting with a more anatomically 
correct position. If you want to use an 
anatomically correct spine, don't make 
the common mistake of placing it too 
close to the skin of the back. The visible 
bumps you see on the human back aren't 
vertebrae— they're caused by the fin-like 
extensions called "spinous processes," 
and they can be several inches from the 
real pivots of the spinal bones. At the 
forward most point of the lumbar curve, 
the pivot point is actually almost at the 
centerline of the body. So check some 



anatomical reference. As 
always, go with what looks 
best for your character not 
with what you read— not 
even here! 

BELLY BONES 

With modern vert counts, 
careful vertex weighting 
is often all you need to 
get reasonably good 
deformation with an 
anatomically correct 
spine. However there 
will be plenty of 
cases— particularly 
on characters whose 
physique or clothing 
gives them more 
prominent bellies, 
where the crunching 
effect of the rearward 
spinal placement will 
become unpleasant. 

Usually, a very 
simple fix-up is usually 
all that's needed to bring 
crunch-collapses under 
control. The easiest fix is to 
use a single extra bone 
located behind the navel in 
the mass of the abdomen. 
Parent this to the vertebra 
closest to the navel, and use 
driven keys to push it forward 
in the parent bones' local 
space as the lumbar region 
flexes. 

The key to making this 
work is never to weight any 
verts exclusively to the belly 
bone. Instead, make sure 
that it has a gentle effect 
(less than 50 percent on any 
given vertex) and a soft 
falloff. Also, take care that it 
has little or no effect on the 
solid mass of the ribcage. 

Pushing the "belly bone" 
forward alongthe local 
forward axis of its parent 
vertebra helps counteracts 
the loss of volume from the 

CONTINUED ON PG 40 
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FIGURE 2 The four major regions of the 
spine are shown. 




FIGURE 3 Because the rest pose of the 
cervical vertebrae is curved, raising your 
head and lowering it produce noticeably 
different motions. 
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Doom 3 might be even more frightening with 
a more dynamic soundtrack. 



THIS SPACE IS USUALLY RESERVED FOR 

advice, tips, and tricks for game audio, 
but I want to take a different approach 
this month. In this column, I will offer 
some constructive criticism that applies 
primarily to the action adventure genre. 
God of War, Halo 2, and Fable are all good 
examples, but for the purposes of this 
article, I'll be discussing two excellent 
games— Doom 3 and Half-Life 2. These 
games are both utterly beautiful and 
have effective sound effects, but in my 
opinion don't make many advances with 
their soundtrack. 

Although they are masterpieces of the 
genre, Doom 3 and Half-Life 2 just aren't 
as progressive with their music design, a 
trend I'm noticing more and more. 

FEAR FACTOR 

I want to discuss Doom 3 first— the latest 
game in the series that IBM and Hewlett 
Packard banned from their networks due 
to lost productivity. 
When you start up Doom 3, the CD launch 
window presents you with 
a very loud, low, eerie, 
ambient drone, which 
certainly sets the mood 
and lets you know that this 
is not your dad's Doom. 
After the Id logo screen 
completes (which has even 
more creepy imagery, and a 
memorable heart palpitation 
sound effect), you meet 
the title screen, with music 
by Chris Vrenna. The initial 
electronic instrumentation 
is lilting and foreboding, 
and brings you that much 
closer to reliving a new and 
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super enhanced version of the original 
title. Then the guitars kick in. 

Rather than present a memorable 
theme, a rather generic riff was used. I 
was sorely disappointed. 

While Bobby Prince's marriage of power 
chords and 12 bar blues didn't exactly 
make the first Doom 's soundtrack pop, at 
least you could remember the themes. 

Doom was impressive at the time, and a 
massive step forward for 3D, but was still 
a rather cute game, and wasn't really 
about instilling fear in the player. Bobby 
Prince's soundtrack played on this, and it 
truly was enjoyable to watch imps 
explode to the driving rhythm of 
instrumentation that seems quite quaint 
by today's standards. 

Doom 3 though, has fear written all over 
it, and it's difficult to open a door without 
your heart jumping out of your chest. The 
game is a triumph of graphic engineering, 
with some good environmental sounds to 
boot, so the lackluster soundtrack is 
even more apparent. 

With the extremely rare ambient drone 
and occasional electronic mini motif, the 
game is relatively music free. In these 
frightening moments, music could be 
used to increase the tension even more. 
Think of movies like>4//en, Vertigo, and 
Terminator 2. Now imagine them without 
music— they're not nearly as effective. 
Doom 3 could have used that edge. A few 
well placed stingers and more use of 
creepy ambient tension tracks would 
have gone a long way. 

a soundtrack half-lived 

Then there's Half-Life 2. It's a great game, 
and a constant jaw-dropper, from the 
clever design mechanics to the incredibly 
beautiful environments. The game was a 
huge leap over its predecessor in all 
respects, save one. The model for music 
remained exactly the same. There's only 
the odd action track during the more 
intense battles (such as one or two 
points duringthe airboat sequence), and 
every so often there is an opening piece 
that will give you a musical sense of the 





Half-Life 2's emotional atmosphere would be a 
good showcase for a strong musical theme. 



level's intended theme, along with its 
chaptertitle. 

This was the model used for the first 
game as well, and doesn't heighten the 
drama very much. Having said that, the 
absence of music is utterly important to 
games like these, and there really 
shouldn't be any music at least 30 
percent of the time. However, just as with 
Doom, the soundtrack could have served 
to bring the player a sense of dread, or 
foreboding, or simply to enhance the 
feeling you get when staring out over 
that gigantic bridge that made you sweat 
profusely when crossing. I can't say that 
the game would have sold better if there 
had been a propertheme, but while 
playing I was constantly identifying 
areas that could have benefited from a 
well-placed stab, or an Absy nth drone, or 
even a theme for Gordon Freeman! The 
story, while somewhat sparse, made you 
feel far more heroic, a savior of mankind, 
and while the voice over communicated 
that, the music did not. 

There's no question that both of these 
titles deserve credit for making great 
steps forward in games. And I'm not 
saying that all games should have music, 
either. Music isn't a prerequisite. 
However, games that lift you out of 
reality, especially those that present 
drama, deserve an original soundtrack— 
and games that deliver such intense and 
incredible experiences as Half-Life 2 and 
Doom 3 deserve better ones. :•: 
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RULES OF INTEREST 



ATTHE UPCOMING GDC IN MARCH 2006, 

Hal Barwood and I will present an update 
to The 400 Project, the quest to collect 
rules of good game design. We don't have 
400 rules yet, but we're well on the way, 
and it's almost time to make the list 
public. As a preview, here are brief 
versions of rules from various designers 
that all address the issue of how to keep 
players interested in a game. 




Monkey Island II followed the rule: "Players should see their 
goal before they can achieve it." 

My favored description of a good game 
is "A series of interesting and meaningful 
choices made by the player in pursuit of 
a clear and compelling goal." Here's how 
to make those choices interesting and 
meaningful to the player. 

MAKE CHALLENGES VARY IN MORE THAN 
DEGREE — E. Daniel Arey, Naughty Dog 
(Jakand Daxter) 

Dan Arey warns that a series of 
challenges that vary only in degree, for 
example enemies that come in waves of 
increasing numbers but are otherwise 
identical, will bore the player. Instead, 
make enemies that vary the player 
response in terms of strategy, tactical 
button presses, timing, reaction, and 
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opportunity so the game stays fresh and 
engaging across the entire difficulty 
ramp-up. This rule is a specific case of an 
earlier, more general rule "avoid player 
fatigue," the admonition to avoid the 
paired threats of boredom and frustration. 

DON'T MAKE YOUR OBJECTIVE YOUR 
PRIMARY THREAT-Brian Upton, Red 
Storm (Rainbow 6) 

Brian explained that if the main quest for 
the player is killing an ogre chieftain, the 
smaller challenges alongthat quest 
cannot consists only of defeating weaker 
ogres. This is also a specific version of 
the "avoid player fatigue" meta-rule. 

MAKE THE PLAYER FEEL SMART-David 

"Zeb" Cook, Cryptic Studios (City of 
Villains), Gordon Walton, ex-Three-Sixty 
Pacific (Harpoon), and others 

Many designers suggested this rule; a 
practical suggestion on how to implement 
it is to give the player a deliberately 
imperfect tool or set of characteristics that 
he or she can improve over the course of 
the game. For instance, you may start 
them in an RPG with a weapon that is 
merely average, and let them find or make 
one that is perfect for their character, or 
start them with a sports team that has a 
few sub-par players. Then let the player 
"discover" a fix for that problem in a way 
that lets the player feel smart. 

PROVIDE MULTIPLE SOLUTIONS TO 
PROBLEMS— Warren Spector, ex-Ion 
Storm (Deus Ex) 

This rule suggests a good way to avoid 
frustrating the player. If there are multiple 
solutions to a problem, there is less 
chance of getting caught in a dead end. 
The different solutions should also take 
into account the different preferences 
and abilities of players. One tried and true 
method is to provide at least one solution 
that requires fast action and good 
reflexes, and another that depends more 
on intellectual prowess. 



PLAYERS SHOULD SEE THEIR GOAL 
BEFORE THEY CAN ACHIEVE IT-Ron 

Gilbert, ex-LucasArts (Secret of Monkey 
Island 1 and 2), Warren Spector, and others 

This is another common rule that I first 
heard Ron state in the old graphic 
adventure days: "No backwards puzzles." 
Letting players see (or at least hear 
about) their goals before they can 
achieve them builds anticipation and 
makes the payoff sweeter. Don't give 
them the key they need before showing 
them the lock, whether a literal key or a 
piece of information, a critical tool, 
artifact, or weapon. One trump to this rule 
is to give players the key but disguise it 
or mask its power, only to reveal it at the 
right moment for effect. Remember 
Dorothy's ruby slippers! 

MAKE CHALLENGES REQUIRE SKILL — 

Raph Koster, Sony Online (Star Wars Galaxies) 

Raph Koster expounded on this rule 
colorfully: "Don't make a task so simple a 
dead monkey could do it." A trumping 
domain where this rule is weaker is the 
tutorial or first level of a game, where 
tasks should be easy and painfully 
obvious— but even there it would be good 
to require at least a modicum of skill. 

TUNE FOR PLAYERS AT THE CENTER OF 
THE SKILL CURVE-Gordon Walton, Sony 
Online 

Gordon Walton clarified that if you tune 
for power gamers, who may be the vocal 
minority, you will leave behind the vast 
silent majority of players. Users of this 
rule also should take into account the 
audience for which the game is intended. 
But even if most of the players of Gorefest 
VII: The Bloodletting will probably have 
played Gorefest VI: The Crimson Flood, it 
makes good economic sense to keep the 
game accessible to new players who can 
expand the franchise. :•: 
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Full-Time, Tenure-Track Faculty 
Interactive Arts and Media 

We are a diverse, open admissions, urban institution of over 10,000 
undergraduate and graduate students emphasizing arts and communications in 
a liberal education setting. The Interactive Arts and Media Department (1AM), is 
seeking a full-time, tenure-track faculty member with expertise in Game Design, 
Game Art and/or Game Programming to begin mid-August, 2006. 

The 1AM Department offers degrees in Game Design, Interactive 
Multimedia and Digital Media Technology. The new Game Design 
major has four concentrations, including design, animation, sound 
and programming. 

The candidate will demonstrate the creation of innovative games and 
game paradigms in a sustained professional or academic capacity. 
Experience with serious game design is desirable. Responsibilities 
will include teaching game-related courses which include media 
theory, interdisciplinary approaches and industry practice. 

The successful candidate will have an advanced degree in 
addition to significant professional accomplishments and teaching experience 
at the college or university level. All new tenured and tenure-track faculty 
members must show evidence, prior to being hired, of active involvement in 
their discipline. Recent graduates must show distinct and clear promise. 

We offer a competitive salary and excellent benefits package. Minority and 
women applicants are especially encouraged to apply. Applicants seeking the return 
of their portfolio samples should include SASE. Please send a letter of application, 
a statement of teaching philosophy, a CV, work samples/portfolio and three names 
with contact information for references to: David Gerding, Interactive Arts and 
Media Faculty Search Committee, Columbia College Chicago, 600 S. Michigan 
Ave., Chicago, IL 60605. Alternatively, submissions may be submitted electronically 
t o dgerding@iam.colum.edu. For serious consideration all application materials 
must be received no later than January 15, 2006. 

Equal Opportunity/Affirmative Action Employer M/F/D/V 
www.colum.edu 
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crunching of the abdomen. Moving it up in the bone's local space helps keep 
the mass of the abdomen from sliding down into the pelvis during the bend. If 
your engine supports non-uniform scaling at runtime, you can also try some 
subtle scaling to reflect the drooping of the belly mass (unless, like the 
author of this column, your character has rock-hard six-pack abs). 

Naturally, the belly bone is a great place to add some secondary motion 
to the soft mass of the belly. If you need hand-animated secondary on top 
of the automatic volume fix-up, add an animatable child to the automatic 
belly bone for the manual tweaks. 

SKELETAL FUNCTION 

The focus of this series is on deformation skeletons, rather than animation 
rigs, so this isn't the place to delve into the details of rigging spines. It's 
worth mentioning, though, that using naturalistic spines is a great 
counterpart to using spline IK rigs, particularly if you're building the spine 
using more than six or seven bones. Properly built spline rigs do a great job 
of capturing the fluid lines of a well-built spine. Unlike simple FK rigs, they 
also keep the number of keyframes to manage to a reasonable minimum. 
For more detail about the pros and cons of different spinal rigs, check out 
"Get Some Backbone" (November 2004). 

That's about it forthe topic of spinal anatomy for animation. Next month 
we're going to take a break from the anatomy lesson, but we'll return to the 
boneyard in a few months. In the meantime, take the opportunity to check 
out some anatomy resources on the web and experiment with some 
alternative construction methods. It's always a good idea to revisit settled 
habits once and a while. :•: 
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the high profile of the franchise, and although 
there have been some critical highlights for the 
PAC-MAN series, some argue that the lack of a 
consistent creative overseer has caused the 
series to lack direction. In fact, with his fun-yet- 
simple design tactics, one wonders what a 
second Iwatani-helmed PAC-MAN game might 
look like. 

3 FRANCHISES CAN BE BUMPY. Every 
franchise has them— from THE LEGEND OF 
ZELDA's horrid interactive CD-i games through 
some of CASTLEVANIA's stuttering 3D iterations. 
Unfortunately, the same is true for the PAC-MAN 
franchise. Along the 25 years of fun, there have 
been a few mis-steps. This is particularly true of 
titles that try to stray too far from PAC-MAN's 
original maze chase genre. Many humanoid 
mascot characters have multiple natural 
extensions; as ambulatory humans, they can be 
in a platformer, a racing game, a tennis game, a 
baseball game, all without changingtheir 
intrinsic nature or design. PAC-MAN, on the other 
hand, needs to sprout arms and legs, neither of 
which are part of his original design, in order to 
leap out of his 2D maze. 

Although these changes can work in video 
game form (as in PAC-LAND), other extensions 
can just end up feeling a bridge too far for our 
plucky friend. A prime example is probably party 
game PAC-MAN FEVER, which traded off the PAC- 
MAN name to relatively little interest and 
unfavorable critical reception, though early, 
quirky titles such as PROFESSOR PAC-MAN also 
seemed to take the franchise name down an 
inappropriate cul-de-sac. The bottom line, as with 
all franchises: things work less well when their 
branding or characters are added to genre-based 
titles that aren't actually enhanced by their 
presence in terms of gameplay. 

PAC IT UP 

There's no disputing the pervasiveness of the 
PAC-MAN iconography, and in that sense, the little 
yellow fellow's quarter century has been 
overwhelmingly successful. As journalists and 
former game developers ourselves, we've been 
interested by the ways that the PAC-MAN 
franchise's game designs have grown and 
morphed over the years, despite the apparent 
perfection of the original game concept. 

Though it's clear that PAC-MAN's genesis has 
made him a handful during his teenage years, 
now he's in his 20s and settling down to a life of 
contented ghost-chomping. And who knows— 
another golden age of power pill consumption 
may be just around the corner. Here's to another 
25 years of "wokka wokka wokka!" :•: 
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lias MotionBuilder®7 the world's leading 
productivity suite for 3D character animation, gives 
technical directors and artists the ability to handle the 
most demanding, high volume animation challenges. 

New and improved character animation functionality 
and exceptional productivity enhancing features make 
MotionBuilder 7 a complementary package that can 
improve any existing production pipeline. 

Visit www.alias.com/motionbuilder to find out how 
the ultimate productivity tool for professional quality, 
high volume 3D animation will allow you to achieve 
amazing results faster than ever before. 
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The Miles Sound System 7 supports 2D, 3D, streaming, MIDI with 
DLS, MP3 decoder (with patent rights), voice chat, software 
reverb, multichannel audio (5.1 and up) and much more! Avail - 
mrt * Yi** m able for PC, Mac, Xbox, Sony PlayStation2, and next-gen consoles. 







Pixomatic Is our powerful software renderer for PCs. Essentially, 
it is a high-end DX7 video card in software form! MMX, 3DNow, 
and SSE optimized assembly is generated at run -time. Don't let 
low-end hardware or bad video drivers hurt your game's sales! 

Cranny Is a powerful toolkit for building all kinds of interactive 
3D applications, it features the most efficient and flexible 
content exporters, data manipulation, normal mapping and 
run-time dynamic 3D animation system you'll find anywhere. 

Bink is the finest video codec for games! It provides better than 
DVD quality at half the data rate along with a perceptually lossless 
10:1 audio codec in a simple and clean API. Available for PC, Mac, 
Xbox, CameCube, Sony Playstation2 and next-gen consoles. 
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